Agent 接手任务后，先收紧的是工作单元

最近看一圈关于 Agent 的讨论，最后总会回到同一个问题：一块活到底该交给谁，交出去之前要包成什么样，拿回来以后又怎么验收。这个问题一旦落到项目里，先抬高的往往不是模型费用，而是工作单元的复杂度。任务切得太大，模型会显得“好像能做”；真正出问题的地方通常在回滚、复现和验收。

工作单元先要能验收

这几天把 Martin Fowler 的那篇碎片笔记和 Thoughtworks Future of Software Development Retreat 的几段讨论串起来看，最明显的感觉就是：会议里聊的表面上很散，底下其实只绕着一件事转——把多大一块工作交给 Agent。

Kief Morris 的整理最直接。不同 session 讨论的是 code review、生产事故、团队分工、模型路由，看起来各说各话，收起来却是同一个判断：人们一直在调整“单位工作”的大小。这个单位越大，交出去越省事；单位越大，回来以后也越难验收。模型不是不会做，而是后面的确认链路先撑不住。

这也是 harness 被反复提到的原因。context management、computational sensors、property-based testing、formal methods，这些东西听上去像附加工具，实际是在收工作单元。有人把 agents.md 控到 200 行以内，不是为了追求形式上的整洁，而是在逼系统只接收那部分真的有用、也真的能被检查的信息。上下文太松，Agent 当然能跑；只是跑完之后，没人知道它到底把哪一层约束吞掉了。

自托管把控制面抬上来了

自托管模型的讨论也指向同一件事。token 变贵、合规要求变严、数据不能外流之后，开源模型和本地模型自然更有吸引力。可一旦自己扛起模型，麻烦也一起抬上来：GPU、推理机房、路由、回滚、fine-tuning、模型选择，这些都不是模型能力本身，却会决定系统最终能不能稳。

这类成本常常被低估。很多团队一开始盯着“模型有没有更强”，后来才发现，真正消耗时间的是把工作单元在多个模型之间稳定转手。什么时候用大模型，什么时候用轻模型，什么时候干脆用本地模型，靠的不是口头偏好，而是一层能做分流和兜底的控制面。没有这层东西，自托管就会从“掌握主动权”滑成“自己把运维复杂度接过来”。

Simon Willison 提到让更强的模型自己挑更小的模型做活，这个思路也很像控制面在做的事。模型本身不一定知道团队的成本边界，但系统可以知道。把模型当 broker，用它去分配任务，比一味追求单模型全包更接近真实交付。

验收和目标不能外包

Sam Ruby 那场 “Bring me a Rock” 把另一个问题挑明了。把工作交给模型，等于多了一个执行者；责任并不会因此消失。管理者可以用 LLM 做探索，可以让它先吐一堆候选方案，但最后的验收标准还是要落在人手里。隐藏目标最麻烦，权限、隐私、破坏性动作、上下文泄露，这些往往都没写进最初那句需求里。

所以 conformance tests 往往比规格书更有用。规格书擅长描述“要什么”，测试更擅长暴露“不能发生什么”。Agent 系统里尤其如此。模型可以把显性的目标补得很像样，隐含的边界却需要靠更硬的校验去兜。只要验收条件还停留在模糊描述里，Agent 做得越多，系统越像在赌概率。

因此代码审查、事故处理、任务分配这些原来很像人的工作，现在开始出现别的形态。管理者直接拿模型来用，表面上像在提效，底层其实是在换一种管理方式：从管方法，转成管目标。目标写得清，模型才有机会干活；目标写不清，模型只是在替人放大模糊。

经验和阅读能力还在往上走

Dan Davies 提到的 interactional expertise 和 contributory expertise 也很贴这个变化。模型能读很多材料，能拼出一个像样的判断，但系统要稳定，还是得有人能读规格、能看结果、能知道哪里不对。这里的关键不是人要和模型比谁更聪明，而是人要继续站在能定义边界的位置上。

这件事放到软件交付里就更直白。Agent 接手之后，人的工作会更少地落在手工执行，更大比例地落在任务切分、边界定义、验收设计和例外处理上。任务能不能被清楚地转交，决定了后面的上下文管理、模型路由和工具编排值不值得做。单元不清，层数再多也只是把问题往后推。

这几天读完这些碎片以后，脑子里留下的不是某个模型名，也不是某种新框架，而是一个更朴素的判断：Agent 系统先要收紧的，不是模型能力，而是工作单元。单元小一点，验收硬一点，权限收一点，系统才有机会把复杂度压在可控范围里。