agently-design

Agently Design

在需要跨所有者设计和审计时使用此 Skill。它会生成所有权与交接契约；不会变成调度器、TriggerFlow 定义、TaskDAG、重试引擎或 RuntimeEvent 协议。

对于迭代式设计或评审，请在回复开头展示当前事项和带时间戳的版本化变更日志；区分决策与已应用、已验证的变更。阅读多轮协作。

项目阶段与范围

根据现有资产和证据，判断任务属于新设计、部分实现还是生产审查。简要说明判断依据，并阅读项目阶段，了解对应的问题和交付物。只询问会实质性改变设计的缺失信息。以业务目标、约束和足以满足需求的最简单方案为起点；如果精确查询或确定性程序足以解决问题，就不要引入模型。这并不意味着可以用关键词规则替代语义判断。

不要假定模型、SDK 或框架已经选定。对于尚未选定或明确采用不同技术栈的情况，先用中立角色描述契约，并遵循该技术栈；只有在 Agently 属于范围时，才应用 Agently 所有者/API 映射。仅进行本次设计审查并不代表获准迁移框架。尚未明确的产品/项目形态仍由 agently 负责；跨所有者设计由此处负责，而已明确的单请求或运行时问题仍由其现有机制所有者处理。

核心工作流

1. 说明业务决策和完成不变量。
2. 将每项决策归类为模型负责的语义工作、宿主负责的确定性工作，或混合型的有界枚举/键决策。
3. 为每项决策、状态、效果和等待指定一个现有所有者。
4. 在选择 API 之前，绘制请求时的值依赖关系和执行时的事件依赖关系。
5. 只有在后续字段不需要调度后才产生的观察结果时，才将有序字段合并到一个 ModelRequest 中。如果后续模型决策需要 Actions、系统访问、审批、制品回读或宿主计算的结果，则应在这些步骤之后拆分。
6. 根据获授权的使用方推导每个提示词/输出字段，并声明其类型、约束、可见性、保留策略和故障行为。
7. 在实现之前设计证据、规范身份关联、生命周期、收敛、压力和观察机制。
8. 对于审计，应重建已观察到的拓扑，并找出最早出现分歧的节点或边，而不是根据最终输出推断根本原因。遵循可观测性与验证中按顺序排列的诊断关卡：执行可达性、执行逻辑、实际模型输入、有界 Prompt 实验，然后在调优失败时进行获授权的更强模型对比。如果有 DevTools 证据或审阅者评论，请通过评审工作流阅读，核实源证据，并将重新运行的发现反馈给原评审。
9. 将具体实现交给负责相应机制的 Skill。

必需的拓扑约定

对于实验报告和设计文档，如果任务说明不是英文，优先使用该说明所用的语言撰写完整文档；双语版本也可以接受。明确指定的输出语言优先级更高。此要求适用于文档本身，而不仅是聊天摘要。 根据需要保留代码、标识符、原始提示词和证据；这些内容所用的语言不决定报告其余部分的语言。

如果协作审查能够回答开发者关于模型节点定义、执行影响、数据完整性／冗余或模型／Host 分工的问题，就应采用协作审查；无需要求使用“Prompt review”这一短语。 首先展示完整的审查范围内流程，同时突出模型节点、其职责、输入／输出交接以及 Host 工作。针对问题与证据的核查，请阅读 references/model-request-topology.md。使用现有拓扑，不要另建台账；仅有图示不足以证明运行时正确性或质量。 按 ../agently-request/references/prompt-management.md 将相关节点表组合起来比较：最多三个逻辑节点可以共用一条回复；紧密耦合的较大节点组也可以组合。可在同一条回复中展示明确的审查范围及其详细信息。保留对重大变更的确认，并在修订后仅重新审查受影响的职责／交接。

每个非平凡的线性、分支、并发或循环应用都必须包含：

• 责任归属／不变量台账；
• 计划节点台账，列出每个 ModelRequest 或 Host 阶段及其边界原因；
• 值／事件边台账，注明确切的生产者、验证方式和消费者；
• 针对每个所需节点、字段和产物的生产必要性台账。

仅当交接处的小型项目自定义参考数据能够支持独立消费者、并行开发、重放、本地验证或故障定位时，才使用这些数据。应如实标注模拟数据，并证明真实生产者的输出可以替换它。不要臆造通用交接数据包。

非终端模型结果应视为阶段范围内的贡献：它必须满足本地契约并产生可观察的进展，但无需声称整个任务已经完成。未知或延期的工作必须明确保留；终端结果和不可逆影响仍须满足完整验收要求。

按设计问题阅读

• 责任矩阵、项目层、术语、状态／存储，以及稳定流程与已提交 DAG：references/system-boundaries.md。
• 模型节点定义、效果调优、数据流正确性／冗余、以流程为先的审查、提示词／输出契约、同一回复中的消费、扇出、汇合和 instant：references/model-request-topology.md。
• 完整的计划值／信号与实际值／信号审计：references/execution-topology-validation.md。
• TaskContext 数据包、TaskWorkspace／RecordStore 证据、可信选择键、引用、引文、快照及故障关闭式汇合：references/information-and-evidence-design.md。
• 并发、重试、修复、重新规划、审批、暂停／恢复、取消、关闭、压力，以及计划的长篇章节生成：references/lifecycle-and-pressure-design.md。
• RuntimeEvents、血缘关系、请求遥测、模型质量审查和实验比较：references/observability-and-validation.md。

明确责任归属后：

• 单一请求系列归入 agently-request；
• AgentExecution 插件／最终策略、Action、MCP、ExecutionResource、TaskWorkspace、RecordStore、服务或遥测机制归入 agently-runtime；
• 开发者自有的可执行编排归入 agently-triggerflow；
• 明确提交的 TaskDAG 数据仍属于低频的 agently 高级参考内容，而不是独立的默认 Skill；
• 源框架映射归入 agently-migration。

不可妥协的边界

• 仅凭模型参与不足以成为发起另一次请求的理由。仅在确实存在决策、证据、使用方、授权、重试、生命周期或并行处理边界时才拆分请求。
• ModelRequest 是派发时的快照。临时的 instant 输出可以更新 UI 或启动可取消、幂等的准备工作，但不能将该准备工作的结果注入正在运行的请求。
• 向模型提供一个由宿主签发的选择键及相关事实。宿主代码负责验证所提供的键，并重建规范 ID 和元数据。
• 如果某个选择可能跨越缓存、队列、重试、持久化或重放边界，则将其绑定到宿主拥有的语义请求溯源关系，并在查询前验证其时效性。
• 每条可由模型满足的业务规则，都必须在生产者首次尝试前传达给它。有意隐藏的安全或完整性门控仍由宿主负责，并需要明确的失败或终止策略。
• 不要请求隐藏的思维链。仅保留有明确使用方和保留约定、范围受限且针对特定任务的过程字段。

完成检查

实施前，请确认每项不变量都有唯一负责人、每个请求边界都有其理由、每个输出字段都有获授权的使用方、每条临时路径都有失效行为、每个循环都有进度和终止规则、每个跨边界身份都有时效性或关联信息，并且每条验证规则都声明了对应的生产者或明确隐藏的宿主门控。

不要用关键词、正则表达式、分词或本地评分表取代语义路由、相关性判断、规划或质量判断。不要在 TriggerFlow 或 TaskDAG 之外添加并行的执行拓扑。