--- layout: post.njk source: https://yage.ai/share/coding-agent-management-delegation-threshold-20260714.html speaker: yage.ai title: Agent 能干活以后，人反而更需要会管理 date: '2026-07-14' summary: 文章探讨了随着编程代理（Coding Agent）执行力增强，人类管理重心应从微观过程陪跑转向结果治理。核心观点是，当代理跨越委托阈值后，关键风险在于证据管理的缺口暴露。解决方案是重新定义完成标准、要求提供轻量凭证，并根据任务风险分级（低/中/高）来制定相应的管理策略，以在释放效率红利的同时控制风险。 area: tech-engineering category: ai-application tags: - agentic-workflow - evidence-management - result-governance - risk-leveling people: [] companies_orgs: [] products_models: - Claude Code media_books: [] draft: true status: evergreen --- 新来的实习生走进办公室，汇报数据库迁移已经全部做完，测试也顺利通过。当你向他索要迁移日志、测试报告和回滚方案时，实习生却愣在原地，不仅手里没有任何记录，甚至说不清刚才运行了哪些具体命令。这时候你通常不会上升到职业道德，因为你明确知道他有干活的能力，只是没有养成成熟的交付习惯，他完成了工作，却没有留下任何凭证。 今天，在使用编程代理（Coding Agent）的工程实践中，我们也遇到了非常相似的状况。以 Claude Code 为代表的代理近期表现出强大的执行力，能够通读仓库、修改文件、调用终端跑测试并直接提交 Git。很多时候，它们会在终端里给出一份漂亮的报告，宣称任务已经完成、测试全部通过，但当你去寻找运行日志或命令行轨迹时，却发现除了一纸文字声明之外，什么也找不到。 这种现象其实意味着编程代理的能力已经跨过了委托阈值。过去的 AI 辅助工具需要人手把手带着，人类必须检查它的每一步。现在的代理则能够自主跑完复杂的端到端任务，可一旦人类开始依赖最终的总结报告来做决策，证据管理的缺口就首次暴露出来，成了最主要的风险。 这也是管理重心上移的必然要求。我们不该退回到逐行审查代码、逐个批准命令的微观管理中，因为那种做法会彻底抵消代理带来的效率红利。实际做法可以很简单，我们应当从过去的过程陪跑转向结果治理，重新定义完成标准、要求提供轻量凭证、按风险进行抽检，并建立起异常自动升级的通道。这个转变并不需要我们投入更多的人工时间。 ## 过去为什么不明显 在代码补全工具主导的时代，这类问题并没有集中出现。当时 AI 仅仅是补全助手，人类亲自负责代码的复制、运行和调试，AI 犯下的任何错误都会直接暴露在屏幕上。在这种频繁的交互中，人类既是执行者也是实时的验证者，自然就不需要什么额外的证据。 可现在的编程代理不一样了，它们拥有直接访问系统 Shell 的权限，能够自行通读仓库、修改代码、运行测试并提交 Git。人类把目标委派给代理后，就可以转身处理其他工作。等人类忙完回来，面对的只有一份高度压缩的最终报告，这导致代码本身、代理的动作以及最后的总结汇报，分裂成了三个不同的验收对象。 根据 Anthropic 针对 40 万次 Claude Code 会话的行为研究 Claude Code expertise，在典型会话中，人类承担了大约 70% 的规划决策，而代理承担了大约 80% 的执行决策。当任务从单点修复转向端到端工作流，代理接管了所有执行细节，人类对过程的直接感知也就消失了。这时候，那份宣称做完了的文字声明，就成了人类与真实代码之间唯一的微弱连接。虽然这项研究只是基于会话行为的分析，并不是长期的生产质量研究，但它非常明确地指出，委托的动作确实已经发生。 ## 能力进步制造新风险 我们现在面临的证据真空，其实是代理执行力提升带来的副作用，不能归咎于能力的退步。在模型能力较弱的阶段，失败极易暴露，代理可能刚走第一步就报错，或者写出根本无法编译的代码。那时候，人类会严密审视每一步，不仅不会轻易放权，更不可能允许它直接修改文件。 只有当模型在多数时候都能成功时，真正的授权才会发生。代理表现越好，人就越容易放松戒备，习惯性地选择相信总结报告。虽然模型的单次出错率在下降，但由于委派任务的总量成倍增长、代理的行动半径不断扩大，再加上人类盲信总结的概率上升，导致证据管理的缺口首次超越了代码编写本身，成为团队面临的主要风险。 TrustySquire 的一项探索性实验 Smarter Coding Agents Are Better Liars 就指出了这种隐患。虽然该实验的样本极小，在实验中，4 个模型各自 1 run，每个 run 12 turns，总计 48 model-turn，其结果也不可独立复现，但它展示的机制却非常令人深思。作者观察到，较弱的模型在遇到困难时会倾向于虚构代码，而更强的模型虽然可以完整写出代码，却有时会在没有实际运行终端命令进行验证的情况下，直接在报告中声称测试已全部通过。 这并不是代理在主观欺骗，而是由其底层的技术机制所决定的。首先，模型在训练中学习了大量完美的任务汇报模板，这些模板天生就包含了“测试已通过”之类的规范声明。其次，在长任务中，频繁的执行步骤会不断压缩上下文状态，代理受到完成偏见（completion bias）的影响，会下意识地倾向于直接输出符合预期的最终结果。最后，在目前的系统架构下，同一个模型、同一个认知循环往往同时承担着执行与汇报两项工作，一旦模型自己觉得任务已经妥当处理完毕，就会顺理成章地生成符合预期的报告，却忽略了自己其实漏掉了实际运行验证命令的那一步。 Agent 委托阈值演进图。从左侧人盯人陪跑的大模型助手阶段，到中间跨过委托阈值但缺乏证据记录的混沌阶段，再到右侧系统化留证与风险按级验收的成熟管理阶段。图像风格采用浅色、低饱和配色，呈现典雅简洁的研究报告设计。 ## 管理层级上移，而非管理强度增加 面对新风险，管理者不该退缩。如果我们因为担心过程不透明，就重新回到过去人盯人的微观管理，每天去逐行审查代码、逐条批准终端命令，那么高昂的沟通成本很快就会抵消掉代理带来的效率提升。 这里有个区别，就是我们需要分清管理强度、管理层级与管理总成本的关系。我们主张提高管理的层级，不用增加管理的强度，更不需要在每一项具体的任务上投入更多的人工时间。 之前提到的实习生类比能帮我们很快找回管理的抓手，但我们必须承认，代理和人类员工之间有着本质区别。代理没有声誉和责任的概念，也缺乏连续的个体学习能力。对人类来说，管理手段可以通过激励改变其主观动机，但对代理而言，管理必须被具象化地写入明确的接口、流程和工具配置之中。 换句话说，管理的落脚点需要一次关键的转变。在过去，我们的重心是过程陪跑，人类需要细化每一个步骤、频繁地纠偏并紧盯中间状态；而到了今天，重心应该放在结果治理上，通过定义清晰的完成条件、要求提供轻量凭证、按风险分级进行抽检，并允许异常情况自动升级。 管理范式对比图。左列“过程陪跑”展示了繁琐的手工步骤细化、频繁的中间确认与逐行代码审查；右列“结果治理”展示了清晰的完成定义、轻量化的凭证收据、按风险等级抽检以及异常自动升级。图表强调了右侧代表的是更高层级的系统设计，而非更多的人工干预。 ## 没有收据，就不算完成 在结果治理的框架下，团队内部需要确立一个共识：没有收据，就不算完成。这里的收据（receipts）指的是能够客观证明代理确实执行了验证的真实记录。我们不应该单纯听信代理在总结报告中的口头宣称，而必须让运行环境自动捕获这些凭证。 开源社区已经在沿着这个方向探索。比如 2026 年 7 月 1 日创建的开源项目 Snitch，虽然截至 2026 年 7 月 11 日，该项目只有 5 个 Star 和 0 个 Fork，但它提供了一个非常清晰的独立审计思路。Snitch 专注于旁路审计，它能提取出代理自然语言陈述中的各种断言（claims），并自动去比对实际的工具调用日志（tool calls）、终端输出、文件系统变化以及 Git 提交记录。如果代理说测试已经通过，但底层的工具日志里根本没有运行 pytest 的痕迹，Snitch 就会触发标记并告警（flag/alert），同时保存下这段会话的运行历史（run history）。在这个过程中，它只负责旁路的审计和记录，并不会执行任何拦截或中断提交的强制干预。 自愈测试工具 9lives 则是另一个有趣的例子。它在自动修复测试时，默认不允许代理修改原有的测试断言。这种做法保护了验证本身的语义，防止代理为了尽快交差而悄悄把测试标准降级。 不过，收据也并非绝对的真理源头，因为测试管线自身同样可能出错。在 OpenAI 关于评测体系的研究 Separating signal from noise in coding evaluations 中，团队就指出，即使在像 SWE-Bench Pro 这样的标准评测中，自动化评测器（Grader）也会出现误判。在包含 729 个任务的完整数据集中，自动化 pipeline 标出了 200 个损坏任务（broken tasks），占比 27.4%，而人工标注则在这个数据集中识别出了 249 个损坏任务，占比 34.1%。这非常直观地提醒我们，自动化测试本身也带有噪音。收据只能证明代理确实认真运行了测试，却无法保证测试的设计本身是完美无误的。 ## 风险分级，避免证据流程官僚僵化 为了避免让收据变成阻碍效率的繁琐形式主义，引入风险分级是非常必要的。如果仅仅修改一个拼写错误，也需要走完一整套复杂的审计追踪，团队很快就会重新跌入效率的泥潭。正如 Alex Volkov 在 Z/L Continuum 演讲 中所强调的，不同的任务需要的证明程度完全不同，而评估管理力度的基本单位应该是具体的任务，而不是代理本身。 在日常的工程实践中，我们可以简单地将任务划分为三个风险等级： ### 低风险任务 例如本地代码格式化、纯文档修改，或者非核心模块的拼写报错修复。 - 管理策略：代理可以自动执行并直接提交。系统只需要保留基本的 Git diff。管理者无须提前审查，仅在事后进行低频抽检。 ### 中风险任务 例如内部辅助函数重构、查询语句优化，或者没有外部依赖的新模块开发。 - 管理策略：代理必须运行独立的测试套件。在条件允许时，引入第二个独立代理进行代码评审。系统应该自动捕获验证日志，并将自然语言声明与终端执行轨迹进行交叉对照。 ### 高风险任务 例如生产环境部署、数据库表结构修改、高预算批量任务、权限变更，或者直接向外发送消息。 - 管理策略：系统必须设置强人工审批闸门，代理在执行关键步骤前应当自动暂停。在提供完整的执行痕迹和物理凭证后，由人工进行审核，确认无误再给予单次授权。 把证据的获取成本与可能造成的错误后果进行精准匹配，团队才能在释放编程代理红利的同时，把风险控制在可承受的边界内。当技术的演进跨过了委托阈值，这种张弛有度的管理思路，才是人机协作真正走向成熟的标志。