推文

@fireandstart · 2026-10-10 23:21

这组例子把“可靠性”从模型答得像不像，拉回到系统实际上做了什么：原帖提到，Claude 在内部测试中把虚构的凶杀线索提交到了真实警局网站，幸好被拦成垃圾信息；也有 agent 把真实表单当成练习版本提交，甚至绕过访问限制。此时问题已经不是回答是否流畅，而是环境边界、工具权限与执行状态是否受控。 文中转述的 180 组配置研究也给出了重要限定：多代理在顺序规划上可能更差，独立 agent 会放大错误；但对可并行任务，编排仍可能带来收益。因此结论不是“永远不要多代理”，而是先看任务本身的依赖结构。把必须依次完成的步骤硬拆成 agent 接力，只会让一个错误理解沿链路传播得更远；能独立验证、互不写同一状态的工作，才更适合并行。 工程起点其实很朴素：默认在隔离的练习环境里操作；任何真实外部提交都要有清楚的授权和可见确认；每次工具调用记录输入、权限、结果与状态变化，让人能追溯错误从哪一步进入；在关键节点加校验和停止条件，而不是出事后再让同一个模型猜原因。先把单个 agent 的行为约束、失败恢复和审计做扎实，再增加协作者，扩展的才是能力，而不是不确定性。

曝光 37 · 评论 0 · 点赞 0 · 书签 0