卸载WorkBuddy,我重新理解托付感

最近我把 WorkBuddy （5.5.6 ）卸载了。它能读文件、调工具、接知识库，也有 Skill、专家和自动化，功能已经很多了。但连续几次真实任务以后，我发现一个挺荒诞的现象：它会的东西越来越多，我却越来越不敢把一件复杂的事情完整交给它。

所以现在评价一个 Agent，我越来越少看它“还能做什么”，而更关心另一个问题：这件事交给它以后，我还需要盯多久？如果一个两小时的任务发出去，我每隔十分钟还得回来看看，补一句、纠一次、提醒一次，那它其实只是替我减少了一部分操作，事情还是攥在我手里。真正的交出去，是我把目标、材料、规则和验收标准交代清楚，然后可以去做别的；回来以后，要么看到结果，要么至少知道它卡在了哪里。

我把这种感觉叫作托付感。要做到这点，模型够聪明还不够，模型外面的 Harness 也得管用。你可以把 Harness 理解成轨道和红绿灯：它得让模型别跑偏，也不能让它还没到终点，就自己宣布“到了”。

01｜规则写了，不等于真的生效

前几天我遇到一件事。我让 WorkBuddy 对一批材料做验收，这件事以前做过，唯一的执行入口已经写得很清楚，结果再做同类任务，它没走规定入口，自己换了一条路。

新路失败以后，它告诉我：“外部评审这轮没拿到结果。”听起来像外部工具出了问题，但真正发生的是：它压根没有按照规定好的路线走。规则写在那里，和规则真正生效，是两回事。

我们可以在文档里写：“这一步不能跳过”“必须走这个入口”“完成以前必须检查”。可如果它跳过去以后，系统什么反应都没有，任务还能继续，最后甚至还能告诉你“完成了”，那这条规则其实并没有真正约束它。一个不报错的约束，不是约束。

这就是 Harness 应该干的事。规定只能走这一条路，其他路就应该走不通；规定验收以后才能结束，验收没过，就不能出现“已完成”。关键地方得真的有护栏，不能只提醒模型一句“你一定要记得”。

02｜检查都过了，事故仍然可能发生

另外一次任务也很典型。那一次 WorkBuddy 做了大量工作，最后跑了接近 200 项检查，全部通过。结果我最后一看，发现两份记录在打架：一份明确写着这个任务有问题，应该停下来；另一份留给后续 Agent 的记录，却还写着“已经完成，可以继续”。

近 200 项检查全部通过了，但我最开始想防住的那个事故，还是可能发生。检查多，不代表真的安全。所有检查甚至可能在自己的体系里互相证明“没问题”，但那个最关键的错误，依然存在。

我看验收结果，会多问一句：用户真正想阻止的那个事故，现在到底还能不能发生？如果答案是“还能”，前面再多的通过，也不能说明事情真的完成了。

03｜把判断和遵守分开

我的原则是：需要判断的，交给模型；需要遵守的，交给系统。两篇文章是不是一个意思，一个方案到底好不好，这些事情没有唯一答案，需要模型理解和判断。但文件有没有放对位置、规定步骤有没有执行、检查有没有完成、任务现在到底是“被卡住”还是“已经完成”，这些都有明确答案，就不该继续依赖模型自己判断。

能让程序检查的，就让程序检查；能用流程卡住的，就不要只靠一句提示。模型可以判断验收结果好不好，但系统必须保证：没验收，就不能结束。不要把本来能够确定的事情，重新交给模型自由发挥。

04｜“做完了”这三个字，凭什么相信

用了 Claude Code、Codex、Qoder 这些Agent 以后，我对办公 Agent 反而更严格。软件工程早就要求 Agent 面对规则、权限、测试、状态和失败恢复，因为这些事情不能全靠模型自己记。办公场景虽然更模糊，但只要一项工作已经有稳定的材料、流程、规则和验收标准，同样需要一套外部运行机制，也就是 Harness。

否则，Agent 功能越来越多，用户还是不敢离开电脑。规则没执行，系统能不能拦住？两份记录互相冲突，它会不会停下来？这些工程问题最后都会落到同一个瞬间：当 Agent 告诉我“做完了”的时候，我有没有理由相信它？

办公 Agent 下一阶段真正值得竞争的，已经不只是“我还能替你做什么”，而是：“有多少事情，你已经敢完整交给我。”