先记住这个答案
交接消息至少要让接收方知道任务是什么、为什么做、可使用哪些已确认输入、允许改动什么、怎样算成功以及结果交到哪里。工程上通常还需要稳定任务标识、父任务关联、输入版本、截止时间、尝试编号和可恢复的状态记录。具体字段名不是所有 Agent 框架统一规定的标准，应按业务契约设计。接收方需要确认接单或拒绝，并在返回时区分已完成、缺少输入、失败和状态未知；交接消息里自报的权限不能替代工具执行端的真实授权。
- 给出目标、输入、范围与验收标准，而非只有行动动词
- 记录任务身份和输入版本以支持重试与追踪
- 确认接单和返回结果都是交接契约的一部分
用验收标准消除独立执行时的猜测
“检查登录问题”缺少输入范围和完成条件，接收方可能去查性能、样式或鉴权。交接应说明用户看到的具体行为、需要检查的提交或文件、允许读取和修改的范围，以及希望收到的可验证产物。已有结论也应附证据来源。
示例把工作限定为只读审查，并要求每项发现给出文件位置和复现条件。base_revision 是受控版本引用，接收方必须解析并确认它指向的实际提交；消息中的 allow_write 只是业务约定，执行环境仍应落实只读权限。
{
"task_id": "review-login-17",
"parent_task_id": "release-review-4",
"attempt": 1,
"goal": "检查登录失败后的错误提示是否保留",
"input": { "base_revision": "review-base", "paths": ["src/login/"] },
"scope": { "allow_write": false },
"acceptance": ["每项发现包含文件位置和复现条件", "无发现时说明检查范围"],
"result_channel": "task-result",
"deadline": "2026-09-06T09:30:00Z"
}该消息提供身份、目标、版本、范围与结果要求，但不包含真实访问凭证。接收端需要解析版本引用、检查期限和权限，再决定接单；消息存在不代表任务已经被接受。
输入引用必须能在接收方环境中兑现
发送方本地临时路径未必能被远端 Agent 读取，动态分支名也可能在执行前发生变化。跨进程交接应使用可访问且有版本约束的产物引用，必要时附摘要和哈希；如果只给截图或自然语言总结，要明确哪些原始证据仍可追溯。
验收结果也应有稳定形式，例如结构化发现列表加证据引用，而不是只说“看完了”。大产物可以单独存储并返回引用，交接消息保留足以判断状态的摘要。这样父任务可以做机器检查，不必再次猜测下游到底完成了哪些部分。
接单和完成之间保留可观察状态
接收方可能发现输入失效、权限不足或期限不合理，应返回明确拒绝或等待更多输入的状态。发送方不能因为消息成功送达就把任务记为已完成，也不能在没有确认时不断创建新的任务身份，造成多个执行者同时处理同一份工作。
恢复时通过稳定任务标识查询已有状态，并保留每次尝试的记录。完成结果若对应旧输入版本，父任务应判断是否仍适用。最终验收责任需要事先约定，避免接收方宣布成功后没有任何模块检查产物是否满足父任务目标。
容易答错的地方
- 把完整聊天记录发过去就完成了交接设计
- 历史对话可能含有已撤销目标、无关信息和过期输入；接收方仍需要明确的当前任务契约与可追溯证据。
- 消息中声明可以写入就等于获得权限
- 权限必须来自可信宿主与执行端校验；下游不能靠修改交接字段扩大可操作范围，也不能转发不必要的凭证。
面试官还会怎么问？
任务标识和尝试编号为什么分开？
任务标识代表同一份逻辑工作，尝试编号记录一次具体执行；这样重试可关联历史结果，而用户真正发起新工作时也能建立新的逻辑身份。
截止时间过了但已经完成怎么办？
返回完成时间和产物证据，由父任务按业务规则判断能否接受；不要因为响应晚到就抹掉已发生的副作用，也不要自动执行第二次。
交接协议需要包含模型的完整推理吗？
通常不需要。可执行目标、已确认事实、关键决策理由和证据更重要，过长的中间过程会增加成本并混入未经验证的猜测。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。