COHAO 共好

把后台管理员账号直接交给 Agent，看起来可以少写很多工具接口：模型想查什么就查，想改什么就改。但一旦出现误删、越权或提示注入，系统很难回答三个基本问题：谁授权的、允许到哪里、怎样撤销。 这种设计会失去什么 对象边界：管理员通常能看到所有租户和用户，模型只靠提示词区分不了所有权。 动作边界：查看、编辑、封禁、退款和改权限被压缩成同一个高权限会话。 责任边界：日志只显示管理员账号，无法区分用户意图、模型决策和工具执行。 故障边界：凭据泄露或插件被污染时，影响范围是整个系统。 更窄的替代方案 为每类允许动作建立专门工具，例如“读取本人订单状态”“为本人草稿生成摘要”“提交待审核的退款申请”。后端从认证会话派生用户与站点，检查对象所有权，限制字段，记录确认和幂等键。 模型不应该拥有数据库、管理员面板、角色修改、钱包或密钥管理入口。即使未来 Agent 更聪明，这些边界也不会过时，因为它们解决的是责任与权限问题，不是语言理解问题。 编辑说明：2026-08-15，本文是上线前威胁建模，不声称 COHAO 已发生该事故。AI 协助起草，项目负责人复核。

下面不是虚构事故，而是一种需要在上线前主动防住的常见失败模式。 假设 Agent 调用“发布文章”工具，外部服务已经收到请求并成功创建文章，但响应在返回途中超时。Agent 只看到超时，于是再次调用，最终产生两篇完全相同的文章。 为什么普通重试策略失效 超时表达的是结果未知，不是执行失败。 创建、付款、发送、删除等写操作通常不是天然幂等。 模型可能把“再试一次”理解为最合理的恢复动作。 如果日志只记录返回结果，没有记录提交前状态，就很难判断第一次是否发生。 应该怎么设计 每次业务动作由后端生成稳定幂等键。 工具先写入 pending 状态，再发送外部请求。 超时进入 unknown，随后用查询接口或外部请求标识核验。 只有后端确认第一次未发生，才允许重新执行。 如果无法查询，就转人工，不让 Agent无限重试。 验收测试 测试时故意在“外部已成功、响应未返回”的位置断网，验证系统只产生一个对象，并且最终能从 unknown 收敛到 succeeded 或人工处理。 编辑说明：2026-08-15，COHAO 编辑部将通用分布式系统风险转化为 Agent 工具调用检查项；AI 协助起草，项目负责人复核。