长程智能体实践总结

基于 Anthropic 的两篇核心工程文章，我将长程智能体（Long-running Agents）开发中遇到的具体问题与解决方案进行了总结，并提炼了超越技术细节的最佳实践。

一、 问题与解决方案

核心问题分类	具体痛点（Problem）	对应的工程解决方案（Solution）
开发效率瓶颈	反馈周期太长：长程任务运行需数小时，工程师每天只能试错几次。	快照与并行化：利用 Docker 镜像建立“检查点”，失败后从中间状态重启；同时拉起数百个沙箱并行运行任务。
开发效率瓶颈	环境不确定性：外部 API 慢、网络波动、模型输出随机会干扰测试结果。	模拟（Mocking）与确定性沙箱：Mock 耗时服务；对同一任务运行 5-10 次以获得成功率的统计分布。
长程连贯性	上下文焦虑 (Context Anxiety)：模型接近上下文极限时会变焦虑，表现为草率收尾、工作质量下降。	上下文重置 (Context Resets)：彻底清空对话记录，通过结构化“工件（Artifacts）”将必要状态移交给全新的智能体。
质量评估缺陷	盲目自信的自评：智能体倾向于赞美自己的输出，即使代码有 Bug 或设计平庸。	三智能体分离 (GAN 架构)：将生成器与评估器分离，微调评估器使其成为冷酷的“怀疑论者”。
质量评估缺陷	测试流于表面：QA 智能体只看代码，不探测运行时 Bug。	物理级交互 (Playwright MCP)：赋予评估器真实的浏览器控制权，让它像用户一样点击、截图、验证 API。
质量评估缺陷	审美同质化 (AI Slop)：AI 生成的设计缺乏个性和原创性，显得平淡廉价。	量化主观标准：制定包含“原创性、设计质量、工艺、功能”的评分表，并给“原创性”设定极高权重。
需求落地偏差	规划级联失败：初期规划太细会导致一步错步步错；规划太粗则导致实现偏离预期。	冲刺契约 (Sprint Contract)：生成器与评估器在写代码前先“谈判”，就“什么是完成”达成书面共识契约。

---

二、 核心最佳实践（工程哲学）

这些实践是 Anthropic 团队在解决上述问题过程中总结出的更高层级的指导原则：

1. 框架即产品 (Harness as a Product)

不要把测试框架看作开发智能体的辅助脚本，它本身就是一个需要投入重兵建设的核心产品。框架的稳定度、速度和反馈清晰度直接决定了智能体能力的上限。

2. “脚手架”减法原则 (The Subtraction Rule)

框架中的每一个复杂组件（如任务切分、上下文重置）其实都是对模型能力的“假设性补丁”。

• 实践： 随着模型升级（如从 Opus 4.5 到 4.6），应主动测试并拆除不再需要的复杂流程。保持框架极简，只在模型能力真正“达不到”的边界处增加复杂性。

3. 结果可回放化 (Observability as a Replay)

对于运行一小时后失败的任务，仅仅看日志是不够的。

• 实践： 必须建立可视化控制台，记录智能体的完整轨迹（思维链、工具调用、屏幕截图、文件 Diff）。定位问题应像“回放录像”一样直观，而不是猜测。

4. 评估优于生成 (Evaluation > Generation)

在长程任务中，提升智能体表现最有效的杠杆不是优化生成提示词，而是优化评估标准。

• 实践： 投入更多精力去定义“什么是好的输出”，并训练/微调评估器去捕捉细微的错误。只要评估标准足够高且反馈足够具体，生成器智能体通常能通过迭代自行找到成功的路径。

5. 战略性决策迭代 (Strategic Pivoting)

长程智能体不应只是按部就班。

• 实践： 指示智能体在接收到负面评估反馈时进行“战略判断”：如果是细节问题则进行增量优化；如果连续几轮分数不涨，则必须尝试彻底转向（如改变整个 UI 风格或技术思路）。