第二章：把用户目标写成可验收的任务

2.1 本书贯穿案例

工作区中有一个 UTF-8 文件 hello.txt，初始内容是 helo, harness\n。目标是把它改为 hello, harness\n，并确认结果。这个任务刻意很小，却已经包含读取事实、提出修改、产生副作用和验证完成四个环节。

模型可以选择怎样组织调用，但宿主有明确约束：只能访问指定工作区，写入需要启用策略，不能覆盖 Harness 的自身状态，不能根据不完整的流参数执行；如果文件已被其他人改动，旧哈希对应的写入应失败。最后必须读取实际状态验收，不能因为助手输出“改好了”就结束。

目标描述想达到什么状态；策略描述运行中允许使用的资源与动作；证据描述实际发生了什么。把三者放进同一段提示词虽然方便展示，却不意味着执行器可以只靠模型自觉遵守。

在实验程序中，目标进入 user.input，写权限由 Policy 决定，工具结果进入 tool.result，最终状态由独立 acceptance 回调核对。这样的分开，使得更换模型后仍能检查同样的结果。模型换成脚本提供方，也不需要绕过工具策略。

至少区分成功、明确失败、被拒绝、被取消与结果未知。“结果未知”很关键：进程可能完成了写入，却在保存结果前崩溃。恢复时看到一个开始事件而没有结果，既不能宣布成功，也不能断言什么都没发生。

因此，任务状态与外部世界状态应分开考虑。一个会话可以暂停等待核查，而文件已经改变。反过来，界面可能展示旧的完成记录，但用户后来又修改了文件；重新打开会话时，应根据当前验收要求决定是否重新核查。

横向比较四套系统时，我们问同样的问题：输入从哪里接受？工具规格由谁确定？一次调用怎样获得稳定身份？执行与记录如何排序？取消后如何收尾？最后由什么条件决定继续？

这组问题比“哪套项目功能最多”更有指导意义。任务的复杂度、可接受权限、部署平台与恢复需求，才会决定你需要借鉴什么。一个研究原型不一定需要插件容器，但只要允许副作用，就需要清楚区分请求、执行与确认。

练习：把“帮我优化项目”改写成一个可验收任务。参考方向是限定模块、说明不能改变的接口，并给出可运行的检查命令或性能样本。不要把“代码更优雅”作为唯一完成标准。