让工具只做该做的事accept不触发write

*写作时间 2026-06-06来自 jp091 深度对话 backlog 候选4

剑飞
1/14让工具只做该做的事 accept不触发write

一个工具承担了太多职责

多Agent协作里有一个常见的工具设计误区 一个工具承担了太多职责

问题决定工具方向
材料决定生成质量
约束决定结果边界
2/14让工具只做该做的事 accept不触发write

用户 accept 了

表面上看「accept 之后自动 write」很合理用户 accept 了 说明内容OK
3/14让工具只做该做的事 accept不触发write

但「合理」不等于「安全」

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“但「合理」不等于「”落到一个具体项目里看结果
4/14让工具只做该做的事 accept不触发write

或者先看看 diff）

命题先说清本页判断
解释补足为什么
行动留下下一步
把“或者先看看 dif”落到一个具体项目里看结果
5/14让工具只做该做的事 accept不触发write

用户会以为一切都存好了

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“用户会以为一切都存”落到一个具体项目里看结果
6/14让工具只做该做的事 accept不触发write

工具跟着问题走

这里有个更隐蔽的问题当两个工具共享同一个资源（比如同一个文件） accept 触发的 wr
7/14让工具只做该做的事 accept不触发write

如果 `accept` 只

如果 `accept` 只做 accept- 成功/失败的状态很明确 - 用户知道接下来要手动 `write` -
8/14让工具只做该做的事 accept不触发write

如果 `accept` 顺

如果 `accept` 顺便做了 `write`- 用户不知道 write 有没有发生 -write 失败时错误信息可能被 accept

命题先说清本页判断
解释补足为什么
行动留下下一步
9/14让工具只做该做的事 accept不触发write

它不负责 `write`

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“它不负责 `wri”落到一个具体项目里看结果
10/14让工具只做该做的事 accept不触发write

但每个步骤的状态都清楚

这样做的后果是每次 `apply_patch` 成功之后用户（或调用方）必须显式调用 `wr
11/14让工具只做该做的事 accept不触发write

当文件权限出错时

」 多了一层不确定性

命题先说清本页判断
解释补足为什么
行动留下下一步
12/14让工具只做该做的事 accept不触发write

带走四步

找项目

从真实任务开始

出材料

把想法变成可处理内容

做交付

用结果判断能力

可复用

把完成沉淀为流程

13/14让工具只做该做的事 accept不触发write

让能力长出来

*写作时间 2026-06-06来自 jp091 深度对话 backlog 候选4

返回原文
上一篇多Agent审稿为什么独立worker更容易发下一篇候选池不是待办清单