长任务 Agent 如何避免擅改验收标准

AI 编程任务一旦跨越多天、多次会话，出问题的地方可能不是模型写不出代码，而是它能改验收标准、接着坏掉的工程继续开发，最后还给自己打高分。作者读完 Anthropic 两篇长期运行智能体研究后，提出了三个结构性约束：限制清单修改权、开工前验证基线、让独立评估者验收。

这篇值得读的地方，是把「交接文档再写详细一点」推进到了权限和流程设计。但完整方案也可能贵得惊人，哪些任务值得用，必须一起算清楚。

验收清单越详细，就越可靠吗

作者每天都在个人 AI 工作流中交接任务，过去一直把交接失败归因于文档不够详细。读完发表于 2025 年 11 月和 2026 年 3 月的两篇研究后，作者改变了判断：问题不只在清单写了什么，还在执行者能修改什么。

按原文转述，第一项研究让初始化智能体把一句需求扩展成超过 200 项的功能清单，保存为 JSON，所有条目最初都标记为未通过。后续编码会话对这个文件只能做一种修改：提供证据，再切换对应条目的 passes 字段。删除条目、改写测试都不被接受。

执行者可以更新完成状态，但不该顺手重写完成标准。

这个约束针对的是一种很隐蔽的偏差：当进度、证据、验收定义都塞在同一份可自由编辑的文档里，智能体可能通过缩小要求，让任务看起来已经完成。它未必在故意作弊，也可能只是整理文档时，把难做的条件一起「整理」掉了。

研究选择 JSON，是因为研究者观察到，模型较少随意改写或覆盖这种格式。但原文明确承认，这只是定性观察，没有量化保证。真正能迁移的做法，是缩小可写范围；换成 JSON，并不会自动获得权限隔离。

新会话的第一件事，为什么不是继续写代码

另一个常见故障，是新会话看到已有进展，就直接宣布完成，或者在已经损坏的工程上继续叠功能。

研究给出的启动流程很固定：确认工作目录，阅读进度日志和最近提交，选出优先级最高的未完成项，然后在写新代码之前，先跑一次基础端到端测试。

如果基线测试失败，就先修复基线，暂停新增功能。每个会话只处理一个功能，结束时留下可继续工作的干净状态。

这里的「基线」，就是接手时工程应当已经具备的可用状态。交接文档说登录完成了，不等于当前代码还能登录；测试能把这两件事分开。

对跨会话的 AI 编程，这个顺序很实用。上一轮留下的描述只是线索，运行结果才是下一轮动工的依据。不过，端到端测试本身也要覆盖关键路径，否则「测试通过」仍可能掩盖实际故障。

独立验收更可靠，但代价可能超过二十倍

2026 年 3 月的后续研究进一步拆开了角色：planner 把需求展开为规格，generator 按 sprint 构建，evaluator 像用户一样操作运行中的应用。

验收条件要在编码前写进 sprint contract，也就是这一轮工作的书面约定。任何一个评估维度低于预先约定的硬阈值，整轮就判定失败。这样，执行者不能等做完之后，再挑对自己有利的标准解释结果。

原文转述的发现是，智能体评价自己的作品时，即使人类能看出质量平庸，它仍可能自信地给出好评。相比要求生成者诚实地批评自己，把另一个评估者调得更挑剔更容易。

但成本不能略过。一个案例中，完整运行框架的费用超过单智能体的 20 倍；对应的单智能体版本有个核心功能不响应输入，而框架版本已经可以游玩。另一个案例花了约 4 小时、约 $124 的 token 费用，评估者第二轮检查仍能发现真实缺口。

这些案例支持的是有条件的取舍：任务超出当前模型独立可靠完成的范围时，独立评估可能值得付费；小型、短时、容易撤销的任务，整套流程可能只是额外负担。

我的判断

我赞成作者把可靠性问题从「模型够不够聪明」拉回工程约束。固定验收标准、先检查已有功能、分离实现和验收，都能减少进度记录与真实状态之间的偏差。

但原文没有交代完整实验规模、各组件的具体收益，以及独立评估者误判的比例。作者个人工作流里的体会，也没有提供对照数据，应该按经验之谈看待。尤其是「每会话一个功能」，迁移到普通团队前，还得先定义功能粒度。

比增加流程更有价值的，是定期删除失效流程。原文提到，新模型到来后，研究者逐项移除组件，发现 sprint 拆分已经可以取消而不降低表现，planner 和 evaluator 则仍有作用。

上下文管理也有类似结果。原文引用 JetBrains Research：直接遮蔽旧工具输出，成本约为保留原始输出的一半，解题率达到或略高于复杂的 LLM 摘要方案；摘要反而让执行轨迹延长了 13% 至 15%。这里没有给出更多实验条件，不能推广成「摘要总是没用」，但足以提醒团队先验证便宜、简单的方案。

流程应该随模型重新验证，不能因为过去有效就永久保留。

能拿来做什么

• 给持续多轮的前端或 Node 任务固定验收条目，让编码智能体提交状态和证据；如果要修改需求，由明确的需求变更流程处理。
• 把会话启动顺序写成固定指令：先读日志和提交，再运行关键路径测试；已有功能失败时，先修复再继续开发。
• 对复杂交互页面，让独立评估者实际操作应用，并依据事先写好的条件验收；简单修改先用现有测试和人工检查，避免直接套上完整框架。
• 更换模型后，逐项停用旧流程做比较，观察完成质量、费用和执行长度，确认哪些组件仍然值得保留。