https://claude.com/blog/building-agents-with-the-claude-agent-sdk，https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents分别讲什么

回复 群友 716： 两篇都是 Anthropic 讲 Agent 的，但层次不一样：第一篇讲「怎么用 Claude Agent SDK 搭一个 Agent」，第二篇讲「Agent 要连续工作好几小时甚至几天时，怎么做才不会崩」。 第一篇 Building agents with the Claude Agent SDK 核心观点一句话：给 Claude 一台「电脑」。Claude Code 之所以能写代码，不是模型变聪明了，而是它拿到了程序员日常用的那套工具——找文件、改文件、跑 lint、执行、调试、再迭代。有意思的是，这套东西做非编程任务同样管用：读 CSV、搜网页、画图、算指标。所以他们把 Claude Code SDK 改名成了 Claude Agent SDK，定位从「编程工具」扩成「通用 Agent 底座」。 文章给的 Agent 主循环是三步：收集上下文 → 执行动作 → 验证结果，循环。举的例子是做一个邮件 Agent： 收集上下文这块，文件系统本身就是上下文工程，把历史邮件放在 Conversations 文件夹里让 Agent 自己 grep；子 agent 可以并行搜多个查询、只把相关片段返回给主 Agent，省上下文；上下文快满了有 compaction 自动摘要。这里有个实用建议：先做 agentic search（让模型自己用 grep 找），别一上来就搞向量检索——语义搜索快但更不准、更难维护、不透明。 执行动作这块，工具是主力，但工具会占上下文，所以要克制；bash 和写代码是万能兜底（比如把附件 PDF 转文本再搜）；MCP 负责接 Slack、GitHub、Google Drive 这些外部服务，不用自己写 OAuth。 验证结果这块最关键，三种方式：定义明确的规则（比如生成 TypeScript 再 lint，比纯 JS 多几层反馈）；视觉反馈（截图回给模型看布局、样式、层级对不对，配 Playwright MCP 自动化）；LLM as a judge（让另一个模型评判，但作者自己说这招不够稳、延迟高，只在收益够大时用）。 第二篇 Effective harnesses for long-running agents 这篇解决的是第一篇没解决的坑：Agent 跨多个 context window 长跑。作者打的比方很形象——像一个项目由工程师轮班做，每个新工程师上班时完全不记得上一班干了什么。上下文窗口有限，复杂项目一个窗口做不完。 他们实测发现，就算用 Opus 4.5 + Claude Agent SDK，只给一句「给我做个 claude.ai 的克隆」，也做不出生产级的东西，两种失败模式： 一是想一口气做完。模型试图 one-shot 整个应用，结果实现到一半上下文耗尽，下一班接手时功能半成品还没文档，只能猜，大量时间花在把基础功能重新跑起来。 二是过早宣布完工。项目做了一部分之后，后来的 Agent 一看「有进展啊」，就宣布任务完成了。 解法是拆成两个角色：一个 initializer agent 只在第一轮跑，搭好环境——写 init.sh 启动脚本、建 claude-progress.txt 进度日志、打第一个 git commit；之后每个 session 都是 coding agent，只做增量。 具体几个关键设计： 功能清单用 JSON 而不是 Markdown，一开始让 initializer 把需求展开成 200 多条可端到端验证的功能（比如「用户能新建对话、输入、回车、看到 AI 回复」），全部标 passes: false。之所以用 JSON，是因为模型对 JSON 不太会乱改乱覆盖。并且明确禁止删除或修改测试项。 每个 session 只允许做一个功能。这条「增量」是解决「想一口气做完」的核心。 每次结束必须留干净状态：git commit 写清楚提交信息 + 更新进度文件。好处是坏改动能回滚，下一班不用靠猜。 测试必须像真人一样端到端跑。他们发现不加明确提示，Claude 会改完代码、跑个单测或 curl 一下，就以为功能好了。让它用浏览器自动化工具（Puppeteer MCP）真的点一遍，效果差别很大。遗留问题是视觉能力有限，比如浏览器原生 alert 弹窗截不到，依赖它的功能就更容易有 bug。 每个 session 开工前的固定动作：pwd 看目录 → 读 git log 和进度文件 → 读功能清单 → 挑优先级最高且没完成的功能 → 先跑 init.sh 起服务、做一遍基础验证，确认上一班没留下坏状态，再动新代码。 文末也说了没解决的问题：到底是单一通用 coding agent 更好，还是多 Agent 架构（专门的测试 Agent、QA Agent、清理 Agent）更好，目前还不清楚；而且这套结论是在全栈 Web 应用上验证的，能不能推广到科研、金融建模这类长任务还在探索。 两篇的关系可以这么放一起看：第一篇讲单次会话内怎么把循环跑通，第二篇讲跨会话怎么接力、怎么不烂尾。你前面看的那篇 OpenAI 的 harness engineering，本质上和这第二篇是同一个问题的两种答案——都强调环境、可验证的规则、Agent 要能自己看到结果。