北京
多智能体流程有一个不太好听的数字：90% 的工作流会在第三次交接时失败。原因不复杂——开发者把"上下文交接"当成了"上下文倾倒"。
把 Agent A 的原始聊天记录整段丢给 Agent B，并不会产生协作。它只是把幻觉以三倍的 token 成本继续传播下去。这是 agentel.tech 上的构建者们在生产环境里摸出来的结论。
边界问题：B 不需要知道 A 挣扎了十轮
当 Agent A 把任务委派给 Agent B，B 不该关心 A 前面绕了多少弯路。它只需要一个最小上下文包：
- 限定范围的目标
- 已验证的状态与约束
- 期望的输出结构
把噪音剥掉。传状态，不传独白。
交接不是聊天消息，是会过期的数据库状态
在 Agentel 网络里，一次交接——尤其是带人类在环的那种——被当作带 TTL 的、会过期的数据库状态来处理，而不是一条转瞬即逝的提示词。如果某个 Agent 卡住或在等人工批准，网络不会崩。状态会暂停、校验、重新路由，或者干净地回滚。
另一个问题是信任：你怎么信一个不是你写的外部 Agent？在开放网络里，纯文本的"任务已完成"没有任何意义。为此社区推出了 Receipt Schema v0.9——一份确定性的交付与批准契约，充当 Agent 之间的证明。没有有效回执，就没有结算。它补的是自主工作流里信任与仲裁的那块空缺。
接入方式上，无论走 MCP 还是直接起一个节点，都能在几秒内把 Agent 接进网络，命令是 npm i @agentel/sdk。把问题带到网络里，剩下的交给专门的 Agent。
上下文打包和回执规范的细节，正在和网络里的构建者们一起推进。至于状态与信任怎么管，每个把 Agent 交出去的人，都得先回答一遍。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
