随着 Claude、GPT 等大型模型不断变强，“AI Agent 能不能自己做一个完整应用？”正在成为开发者讨论的核心话题。许多团队尝试用 Agent 自动构建网站、写 App、跑脚本，甚至维护复杂系统。然而，只要任务稍微复杂一点，Agent 的表现往往让人失望：做到一半就卡住、忘记之前做过什么、自我宣告完成、或者越做越乱。
为什么会这样？ Anthropic 在11月27日发布了一篇博客《Effective Harnesses for Long-Running Agents》，给出了一个关键结论：
问题不在模型能力，而在我们没有给 Agent 设计“像工程师一样工作的结构化流程”。
这篇文章提出了一套可复现的“工程式 Harness（约束/框架）”，能让 Agent 可靠地执行 多轮、多天、跨 session 的复杂任务。Anthropic 用它让 Claude 构建了一个可运行、可测试、端到端完整的 Web 应用。
长任务 Agent 为什么失败？
在 Anthropic 的大量实验中，长任务 Agent 常见两大失败模式：
1. 一次性尝试做太多（One-shot Overreach）
给模型一句话：
“帮我做一个 ChatGpt或者抖音 的完整 Web 应用。”
Agent 往往会试图一口气解决所有功能：
- 前端
- 后端
- 鉴权
- UI 组件
- 数据库
- 网络请求
- 聊天模块
- ……
结果不是代码半途而废，就是跑不起来，更糟的是--模型往往不知道“自己失败了”。
由于 context window 有限，即使使用技术如 context compaction 来压缩上下文，也无法避免细节遗失，导致后续 session 难以接力。
2. 自我宣告完成（False Victory Declaration）
另一种情况是：某个 session 做了一点点功能，下一个 session 的 Agent 看到剩余代码，以为工作已经完成，然后直接“宣布成功”结束任务。
简单说就是： Agent 没有可靠的机制来判断“任务是否真正完成”。
原创文章，更多AI科技内容，微信搜索橙 市 播 客 小程序Anthropic 的解决方式：
“双 Agent + 工程化流程” 的 Harness 结构
要让大型模型像工程师一样长期、高质量地做事，需要一种结构化、约束化的执行方式。Anthropic 的方案很务实：
引入两个明确分工的 Agent + 严格的工程流程，强制项目按 feature-by-feature 分解执行。
角色一：Initializer Agent
--为整个项目建立“秩序与边界”
Initializer 只负责项目启动阶段，创建一个可长期运行的环境结构。
它会：
✔ 创建项目文件结构
✔ 写一个 init.sh 用来启动 dev server
✔ 创建一个 feature list（JSON 格式）
✔ 每个 feature 初始状态均标记为 "passes": false
✔ 写一个 claude-progress.txt
✔ 做第一次 Git commit
最关键的是： 整个项目的未来发展方向，都被明确记录在 JSON 的 feature list 中。
没有这个结构，Agent 的行为会发散；有了它，任务就被拆解成几十上百个原子功能。
角色二：Coding Agent
--每个 session 专注完成一个 feature
所有后续的 session 都由 Coding Agent 完成，但它必须遵守严格流程：
每次 session 开始：统一“进入项目”的流程
pwd：确认当前目录- 读取
claude-progress.txt - 读取
feature_list.json - 查看 Git log
- 运行
init.sh启动 dev server - 跑一次基础 e2e 测试确保项目还活着
这些步骤确保每次 session 都能：
快速获得“工作上下文”，而不需要模型重复阅读一大堆历史内容。
同时也确保 Agent 不会在一个坏状态的项目上继续开发。
每次 session 的核心任务：只做一个 feature
Coding Agent 的工作严格按照下面顺序进行：
① 从 JSON 中选择一个未完成的 feature
② 完成这项功能的代码
③ 运行端到端测试验证功能
--包括用自动化浏览器测试 UI（如 Puppeteer MCP）
④ 更新 feature_list.json（将 passes 改为 true）
⑤ 更新 claude-progress.txt
⑥ 创建 Git commit（写明变化与原因）
⑦ 确保项目处于 clean state
如果测试不过？ → 本次 session 必须回到 clean state，任务不标记完成。
End-to-End 测试：大幅提高鲁棒性
过去很多 Agent 系统用的是：
- 单元测试（unit test）
- 代码检查
- curl 之类的 API 测试
但 Anthropic 发现，这还不够。
真正让 Agent 在 Web 项目中稳定的技术是：
让 Agent 运行浏览器，模拟真实用户点击、输入、交互。
这能捕捉大量“代码看不出、运行就挂”的问题。 例如：
- UI 按钮没响应
- DOM 元素没渲染
- 网络请求 CORS 错误
- 环境变量没加载
- 页面报 JS 错误
虽然仍有局限（如某些系统弹窗浏览器自动化无法捕捉），但效果大幅提升。原创文章，更多AI科技内容，微信搜索橙 市 播 客 小程序
为什么这种方法奏效？
总结一下，这套 harness 让 Agent 更像一个真正的软件工程师，而不是“大语言模型在写代码”：
1. 分解任务避免模型一次性过载
模型不再尝试一次性完成全站，而是 feature 逐个完成。
2. JSON 结构保证任务不会被模型随意篡改
比 markdown 更可靠，模型更不容易破坏结构。
3. Git log + progress log 使跨 session 有连续性
没有真正的“记忆”，但可以“重建上下文”。
4. 自动化测试保证功能真实可用
不是“看上去能跑”，而是真能跑。
5. 清晰一致的 workflow 让 session 之间可靠衔接
每个 session 都从相同状态开始，不会乱。
仍然存在的挑战
Anthropic 在文末也坦率提到一些问题：
1. 当前效果主要验证在 Web App
对于科研、数据分析、DevOps、长脚本任务等场景，仍需探索。
2. 多 Agent（多角色）可能更优
未来可能需要更多专职角色：
- 测试 Agent
- QA Agent
- Review Agent
- Cleanup Agent
- Deployment Agent
类似一个真正的工程团队。
3. 测试覆盖仍有限
某些 UI 弹窗或浏览器原生机制无法捕捉。
结语：
长程 Agent 的未来，不靠更强模型，而靠更好“工程结构”
Anthropic 的这篇文章为一个重要问题提供了非常清晰的答案：
LLM 本身能力强，但要让它长期做事，需要像训练工程师一样训练流程。
未来的主流 AI 工作方式，极可能不是“让大模型从头写个项目”，而是：
“用结构化、可审查、可测试、可衔接的 workflow，引导 Agent 逐步构建完整系统。”
这才是让 Agent 真正落地、可控、可维护的关键。
原创文章，更多AI科技内容，微信搜索橙 市 播 客 小程序
微信扫描下方的二维码阅读更多精彩内容
声明：本站所有文章，如无特殊说明或标注，均为橙市播客原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
