# 我最近两个月的探索和实践分享：长任务 Agent 的最小工程闭环
**作者**: 烟花老师
**日期**: 2026-05-25T15:14:47.000Z
**来源**: [https://x.com/teach_fireworks/status/2058929780880458125](https://x.com/teach_fireworks/status/2058929780880458125)
---
> 一张 Claude 工程师分享的图，把长任务 Agent 最常见的三个问题说得很准：带不住状态，估不准工作量，评不好自己的输出。
很多人第一次认真用 Agent，都会经历一个相似的过程。
> 前十分钟很惊艳。它能读代码、改文件、跑命令，还能自己解释下一步要做什么。
> 半小时后开始不放心。它还在执行，但你已经不确定它有没有记住最初的目标。
> 两小时后，问题变得更明显：它做了很多事，改了很多文件，跑了很多验证，最后交上来的结果却经不起细看。
Claude 工程师那张图把这个问题拆得很准：Agent 会丢状态，会误判工作量，也会高估自己的输出质量。
这三个问题放在一起，就会形成长任务里最常见的失控链路：上下文越来越脏，计划越来越虚，验证越来越浅。最后 Agent 没有突然变笨，只是在一个缺少控制回路的系统里越跑越偏。
所以这篇文章不聊怎么写一个更“聪明”的 prompt。
我们聊一个更工程的问题：如果要让 Agent 稳定处理长任务，系统里至少要补上哪些控制层？
这三层可以当成全文的索引。
Context 管现场，Planning 管边界，Verification 管证据。
任何一层松掉，另外两层都会被拖下水。
## 状态丢失：Agent 的工作台会越堆越乱
很多 Agent 长任务出问题，最早冒出来的信号通常还不在代码，而在状态。
它一开始知道目标是什么，也知道刚刚读过哪些文件。
随着对话变长、工具调用变多、错误信息堆进来、临时判断反复覆盖，context 里的噪声开始变多。到了后半程，它还在继续工作，但已经不像在沿着原来的任务前进，更像是在当前上下文里找一个看起来合理的出口。
这就是 context window 的真实边界。
上下文窗口经常被理解成“模型能记住多少东西”。
这个理解太乐观了。
对 Agent 来说，context 更像一张工作台。任务说明、文件片段、命令输出、错误日志、用户补充、模型自己的中间判断，全都堆在这张桌子上。
桌子变大当然有用，但桌子再大，也不等于它能自动整理材料。
Anthropic 在 Claude Code 最佳实践里讲得很直接：
> context window 会很快被填满，窗口越满，模型越容易忘记早期指令或犯错。它还建议给 Claude 明确的验证方式，比如测试、截图和期望输出，因为这是提升结果质量的高杠杆动作。
这个经验在长任务 Agent 里非常明显。很多跑偏发生在第 40 步、第 80 步，发生在 Agent 已经积累了足够多“看起来相关、实际干扰”的上下文之后。
更麻烦的是 session 之间的状态断裂。一次任务没做完，换一个 session 继续。
Agent 看起来能接上，但它接上的往往只是压缩摘要，只剩压缩后的现场。哪些决定已经确认过，哪些方案被否掉，哪些文件刚改过但还没验证，哪些失败路径不要再试，这些信息如果没有被写进外部状态，很容易在下一轮里丢掉。
所以生产级 Agent 不能把状态全押在 context 里。
最小可用的状态层至少要有几类东西：
这些东西如果只留在对话里，Agent 一旦上下文变脏，就会开始凭印象工作。写进 progress.md、任务 ledger、trace log、issue comment 或数据库，才有机会在下一轮被稳定读回。
这也是很多 harness 设计的第一层价值：
让模型不用靠临场记忆硬撑。
一个好的 Agent 系统，会主动把“工作状态”和“推理上下文”分开。context 里只放当前步骤需要的材料，长期状态放到外部。每次进入新阶段，Agent 先读状态，再继续执行；每次完成一个阶段，Agent 先写状态，再清理上下文。
这听起来像传统工程里的 checkpoint。放到 Agent 里，它更像防止任务漂移的锚点。
没有这个锚点，长任务很容易变成一场上下文赌博：前面写得越多，后面越难判断它到底还记得什么。
## 规划失真：Agent 经常不会判断这件事到底有多大
状态问题解决了一半，长任务还是会翻车。
另一类更隐蔽的失败来自任务尺寸感。
人类工程师接到一个需求，会下意识判断几件事：
这是不是一个小改动？
会不会牵动数据结构？
有没有迁移？有没有兼容问题？验收标准是什么？
这件事适合一次做完，还是要拆成几个阶段？
Agent 经常没有这个尺度。
你让它“改一下文档生成流程”，它可能把整个内容系统都扫一遍。你让它“做一个可用 demo”，它可能只搭一个 UI 空壳。
你让它“修一个 bug”，它可能顺手重构半个模块。看起来都在努力，方向也都说得过去，但任务边界开始松动。
这类问题在长任务里会被放大。
一开始，Agent 倾向于把完整项目 one-shot 掉。
它会列一个很大的计划，把架构、代码、测试、文档、部署都写进去，然后从第一步开始做。
前几步看起来很顺，等 context 用掉一大半，真正难的部分还没碰。
后半程它开始收缩范围，跳过细节，最后用“核心功能已完成”这种话收尾。
另一种情况刚好相反。
它看到局部进展，就把局部完成当成整体完成。
页面能打开了，就说产品可用了；
接口返回 200 了，就说功能通过了；
单元测试过了，就说端到端没问题。很多 Agent 失败卡在一个更早的位置：太快判断“够了”。
这就是任务尺寸感的问题。
规划层要解决的事情很具体：
让 Agent 形成几个硬约束。
- 这次任务的交付物是什么？
- 哪些内容明确不做？
- 每个阶段的完成标准是什么？
- 当前阶段最多允许消耗多少上下文、多少工具调用、多少时间？
- 如果做到一半发现范围变大，什么时候停下来重新估算？
- 如果验证过不了，是否允许继续扩展实现，还是必须先修当前问题？
没有这些约束，计划就只是一个开场白。
Agent 会在执行过程中不断重新解释计划，最后交付一个和最初目标越来越远的东西。
我现在更倾向于把 Agent 规划分成两层。
第一层是任务切分。它回答“这件事应该怎么拆”。这里需要把大任务拆成可以独立验证的小阶段，每一段都有清楚的输入、输出和验收方式。
第二层是运行预算。它回答“这一段最多跑到什么程度”。
包括 max turns、token budget、tool call budget、时间上限、失败重试次数，以及触发人工确认的条件。
这两层缺一层，Agent 都容易失控。
只有任务切分，没有运行预算，Agent 可能在一个子任务里无限探索。只有运行预算，没有任务切分，Agent 会在快到限制时随便找一个能交差的版本收工。
Anthropic 在长任务 harness 的思路里，已经能看到这个方向：
先由 initializer agent 搭环境、列 feature、写进 progress file；
后续 coding agent 每个 session 只处理一个 feature，完成后再把状态写回。Anthropic 把这个问题描述成跨多个 context window 做持续进展的挑战，每个新 session 都需要接上前一个 session 留下的现场。
工程上真正有用的计划，通常不像“我要完成 A、B、C”这么简单。
它更接近一张施工单：
- 当前阶段只做什么。
- 做完以后用什么验证。
- 验证失败如何回滚或重试。
- 哪些情况必须停下来问人。
- 下一阶段要读哪份状态继续。
Agent 更需要边界，不需要鼓励式放权。
边界越清楚，它越像一个可调度的执行单元。边界越模糊，它越像一个勤奋但不可靠的自由发挥系统。
## 验证失灵：Agent 最危险的能力，是把没做对的事讲得像做完了
状态会丢，计划会漂，但这两件事通常还能被人看出来。
验证失灵更麻烦。
Agent 很擅长给自己的工作一个体面的收尾。
它会说“已完成实现”“已通过基本验证”“核心流程正常”。
如果你继续追问，它还能解释验证步骤，列出改动文件，补一段风险说明。
问题在于，这些话有时候只是在替一个很浅的验证包装结论。
最常见的情况是 curl-only verification。
接口能返回 200，Agent 就说功能可用。它没有点过页面，没有走过真实用户路径，没有看浏览器控制台，没有检查数据是否真的写入，也没有确认错误状态怎么展示。
做 Web 应用时，这个问题尤其明显。
一个按钮存在，不代表按钮能用。
页面能打开，不代表主流程跑通。测试通过，不代表用户不会卡在 loading 状态。Agent 如果只在命令行里验证，很容易把“系统有响应”误判成“产品可使用”。
第二种情况是 stub 逃逸。
Agent 做到复杂功能时，会先写一个简化版本。
这个动作本身没问题。工程里经常先用 mock、stub、placeholder 搭流程。问题出在它后面忘了回来，或者把这个临时实现包装成阶段成果。
比如：
- 支付流程只打印日志，没有真实状态机。
- 权限判断写了 TODO，但页面已经放开入口。
- RAG 只返回固定示例，却说“检索链路已打通”。
- 图表数据写死，却说 dashboard 已完成。
- E2E 测试只测 happy path，没有失败路径。
第三种情况是自我评分过高。
Agent 评自己的输出时，经常会发现问题，但把问题降级。它会说“目前实现满足核心需求，后续可优化”。这句话在人工 review 里很常见，但放到 Agent 里要小心。很多关键缺陷就是被这句话放过去的。
真正的问题在于，Agent 没有足够独立的评价位置。
写代码的那个 Agent，天然希望任务收敛。它已经投入了上下文、工具调用和多轮推理，也在接近限制。
到了后半程，它会倾向于把不确定问题解释成可接受风险，把未完成部分解释成后续优化，把浅验证解释成基本通过。
这和人类工程师也很像。自己写的代码，自己 review，严格程度通常不够。区别在于，人类工程师知道团队里还有 CI、QA、代码评审、线上监控。
Agent 如果没有这些外部机制，就会自己宣布自己合格。
所以验证层不能只依赖 Agent 的口头报告。
一个能跑长任务的 Agent 系统，至少需要三类验证：
第一类是机器验证。
能用工具判断的，就不要交给模型判断。测试、类型检查、lint、build、schema validation、数据对账、截图 diff、可访问性检查、日志扫描，都属于这一类。
第二类是环境验证。
Agent 要在真实或接近真实的环境里走一遍。Web 应用要用浏览器点，不只用 curl。数据任务要读回结果，不只看写入命令成功。文档发布要 fetch 回来检查，不只看 API 返回 OK。
第三类是独立评价。
生成者和评价者要分开。
Planner 拆任务，Generator 执行，Evaluator 按 rubric 检查。Evaluator 不负责安慰 Generator，也不负责帮它解释。它只回答几个硬问题：
- 需求是否真的满足？
- 关键路径是否真的跑通？
- 有没有 stub 或 TODO 被包装成交付？
- 失败路径有没有处理？
- 验证证据够不够？
- 如果不够，下一轮该修什么？
这也是 Anthropic 在 long-running application development harness 里强调的方向：
让独立 evaluator 用 Playwright 像真实用户一样操作应用，测试 UI 功能、API endpoint 和数据库状态，避免让生成代码的 Agent 自己说“我觉得可以”
这个设计很重要。
它把“完成”从一句话变成一个证据链。代码改了只是第一步，测试通过只是第二步，真实路径跑通、证据可回放、评价器同意，才更接近可以交付。
很多 Agent 产品现在缺的就是这条证据链。
它们能执行，能解释，能生成日报，能把日志写得很漂亮。
可一旦你追问“你怎么知道这件事真的做对了”，回答就开始变虚。
生产级 Agent 最该警惕的，是系统误判成功。
失败可以重试，可以回滚，可以升级给人。
真正贵的是：它失败了，系统却以为它成功了。
## 工程化 Agent 的五层架构
把前面三个问题放到一起看，会发现 Agent 失控往往不属于单点故障。
状态层没有沉淀，规划层就只能靠当前上下文猜任务进度。规划层没有边界，执行层就会不断扩展范围。验证层不够硬，Agent 就会把局部成功包装成整体完成。监督层缺位时，所有风险都会一路流到最后，由用户自己兜底。
所以生产级 Agent 不能只看模型调用链。
一个更稳的结构，至少要有五层。
1 状态层：让任务有可恢复的现场
状态层负责保存 Agent 不能丢的东西。
包括任务目标、当前进度、阶段产物、决策记录、文件变更、验证结果、阻塞点、人工确认记录。它可以是 progress.md，可以是数据库，也可以是 trace store、issue comment、artifact ledger。
形式不重要，关键是可读回、可续跑、可审计。
没有状态层，Agent 的长任务会变成一次性对话。对话断了，现场也断了。上下文压缩之后，很多细节只剩一个模糊摘要。下一轮 Agent 看起来在继续，实际已经丢了一部分工程现场。
2 规划层：把大任务压成可调度的小任务
规划层负责把用户目标拆成阶段、依赖、预算和停止条件。
这里的计划不能停留在一张好看的 checklist。它更像调度系统里的 job spec：当前阶段做什么，输入是什么，输出是什么，用什么验证，最多允许跑多久，失败几次后停止，哪些操作需要人工确认。
好的规划层会限制 Agent 的自由度。
它让 Agent 每次只处理一个足够小、足够可验证的任务。这样做会牺牲一点“自动到底”的幻觉，但换来更高的恢复能力。某个阶段失败了，可以重跑这个阶段，整条长任务不用一起糊掉。
3 执行层：工具调用只是其中一部分
执行层负责把计划变成真实操作。
读文件、改代码、跑测试、开浏览器、查日志、调 API、写文档、生成图片，都在这一层。很多 Agent 系统把执行层做得很热闹，工具很多、权限很大、动作很快，但前后的状态和验证跟不上，最后反而更危险。
执行层的关键不在工具数量，关键在每次工具调用都能回到任务状态里。
一个命令跑完，输出要进入状态。一个文件改完，变更要进入状态。一个 API 调用成功，读回结果也要进入状态。工具调用如果只在上下文里闪一下，很快就会被后续噪声淹没。
4 验证层：把完成变成证据链
验证层负责回答一个问题：怎么知道这件事真的做对了？
这一层要尽量使用外部证据。测试结果、浏览器截图、数据库 readback、日志、trace、diff、rubric 评分、人工 review，都比 Agent 自己说“已完成”更可靠。
验证层最好和执行层分开。
同一个 Agent 做完再自评，容易把风险解释成可接受。独立 evaluator 会严格得多。它不需要理解 Generator 的全部心理活动，只需要按验收标准检查产物。
这一层越硬，用户越不用自己当最后一道 QA。
5 监督层：控制权限、成本和升级路径
监督层负责 Agent 什么时候能继续，什么时候必须停。
这里包括权限控制、预算控制、loop budget、max turns、危险操作确认、发布前确认、失败升级、人类接管、回滚策略。很多 Agent 工作流表面上追求自动化，实际缺的恰好是这层刹车。
一个成熟的监督层不会频繁打断正常任务，也不会让 Agent 无限自由发挥。它只在几个关键点介入：
- 任务范围扩大。
- 预算接近上限。
- 验证连续失败。
- 操作涉及删除、发布、权限、付费、生产数据。
- Agent 发现自己无法判断。
- 结果影响真实用户。
监督层的价值在于，它把“要不要继续”从模型的临场判断里拿出来，变成系统规则。
这五层合起来，Agent 才从一个会调用工具的模型，变成一个可恢复、可验证、可停止的执行系统。
模型仍然重要。
它决定单步推理质量、代码质量、工具选择能力和异常处理能力。
可一旦任务变长，决定稳定性的往往是模型外面的这些层：
状态有没有沉淀，计划有没有边界，执行有没有记录，验证有没有证据，监督有没有硬停止条件。
## 更强的模型会改变 harness，但不会取消 harness
模型变强以后，很多外层设计确实会变。
以前必须拆成 5 个 sprint 的任务，可能新模型自己就能保持连贯。
以前需要写很细的中间计划，新模型可以在更少提示下做出合理判断。以前必须用专门的子 Agent 查资料，新模型也许能在一次更长的上下文里完成。
这很正常。
每一个 harness 组件背后，都藏着一个判断：
> 当前模型在这件事上还不够稳定，所以系统要补一层。模型能力提高，这个判断就应该被重新测试。继续保留过时的 harness，会让系统变慢、变重，也会制造新的失败点。
Anthropic 在 long-running harness 的讨论里也提到，harness 组件编码了关于模型能力边界的假设，模型换代后这些假设需要重新压力测试。
这个观点很重要。
它提醒我们，harness 不能当宗教。
层数越多未必越专业，角色越多未必越先进。
好的 Agent 架构应该随着模型能力变化而变薄，把不再需要的外壳拆掉，把真正有价值的控制点留下来。
但有几类东西很难被模型能力完全吃掉。
第一类是外部状态。
模型可以读更长的上下文，但真实任务里的状态不只存在于上下文里。文件系统变了，数据库变了，API 状态变了，浏览器页面变了，用户在别处改了需求，权限和成本也在变化。Agent 要持续工作，就需要一个能和外部世界对齐的状态层。
第二类是外部验证。
模型可以更会反思，也可以更会写测试。但“有没有真的点过页面”“数据库里是不是写进去了”“发布后的文档能不能打开”“用户路径有没有卡住”，这些问题需要环境反馈。只靠模型想一遍，永远差一层证据。
第三类是权限和责任。
删除文件、发布内容、修改权限、触碰生产数据、花钱调用外部服务，这些动作不能因为模型更聪明就全交出去。这里需要明确的规则、审计日志和人工确认。模型负责判断，系统负责授权。
第四类是成本。
长任务 Agent 很容易把 token、工具调用、浏览器会话、外部 API 调用变成隐性成本。模型越强，单次调用越贵，越需要 budget routing、max turns、timeout 和 circuit breaker。否则系统看起来很自动，账单也会很自动。
所以更强模型带来的变化，是让架构重新分工。架构不会因此消失。
模型负责越来越多的语义判断、代码生成、异常处理和局部规划。harness 负责把这些能力放进可观测、可恢复、可验证、可停止的流程里。
真正该避免的是两种极端。
一种是迷信模型。
模型一升级，就把状态、验证、权限、预算都交给它临场判断。短 demo 很漂亮，长任务容易埋雷。
另一种是迷信 harness。
模型已经能稳定做的事，还强行拆成复杂流程，最后系统慢、贵、难维护，错误还藏在编排层。
更好的做法是定期问一个问题：
> 这层 harness 现在还在解决真实问题吗？
如果答案是肯定的，就保留，并把它做得更可观测。
如果答案是否定的，就删掉，让模型直接做。
Agent 架构师的工作，不该把模型包得越来越厚。
更准确地说，是持续识别模型当前的能力边界，然后只在边界外补必要的工程控制。
## 长任务 Agent 的最小工程闭环
讲架构很容易讲虚。
真正有用的 Agent 设计，最后要落到一些很具体的动作上：
任务怎么进来，状态写在哪里，谁来验证，什么时候停，失败后怎么恢复。
下面这几种模式，我会优先放进任何一个长任务 Agent 系统里。
Spec-first：先写施工单，再让 Agent 动手
不要直接让 Agent “帮我做完这个功能”。
先让它生成一份短 spec，里面只写几件事：
- 目标：这次要交付什么。
- 非目标：哪些明确不做。
- 约束：技术栈、风格、权限、预算、时间。
- 验收：怎么判断完成。
- 风险：哪些地方可能扩大范围。
这份 spec 不需要长。半页就够。
关键是让任务在执行前先固化一次。
后面 Agent 想扩大范围、绕开验证、提前收工，都可以拿 spec 对照。
Plan gate：计划先过关，再进入自动执行
让 Agent 先出计划，不要马上执行。
计划里必须包含：
- 阶段拆分。
- 每阶段交付物。
- 每阶段验证方式。
- 预计会碰到的文件或系统。
- 停止条件。
- 需要人工确认的操作。
这一步最适合人参与。
你不需要 review 每一行代码，但应该 review 任务拆法。拆错了，后面跑得越快，偏得越远。
很多 Agent 失控，错误从第一张计划就开始了：边界在那时已经放丢。
Progress ledger：每个阶段都写状态
长任务不要只靠对话续命。
每完成一个阶段，Agent 要写一份 progress ledger。
可以是 Markdown，可以是 JSON，也可以是 issue comment。格式简单就行：
```
## Current Goal
...
## Completed
- ...
## Changed Files
- ...
## Decisions
- ...
## Verification
- ...
## Open Risks
- ...
## Next Step
...
```
这份文件的价值在于续跑。
下一轮 Agent 先读 ledger，再读代码。
人也可以扫一眼 ledger，快速知道它到底做到哪里。上下文满了、session 断了、模型换了，都能接回来。
Independent evaluator：让另一个角色验收
生成者不要当最终裁判。
可以用另一个 Agent，也可以用脚本、测试、CI、Playwright、人工 review。关键是评价标准要独立于执行过程。
Evaluator 的输出不要写成“整体不错，有一些建议”。这种话没用。
更好的格式是：
```
Result: PASS / FAIL
Evidence:
- ...
Blocking Issues:
- ...
Non-blocking Issues:
- ...
Required Fixes:
- ...
```
Evaluator 必须有权判 FAIL。
没有失败权的 evaluator，只是总结员。
Browser-level verification：Web 产品必须点过
Web 任务里，curl 和单元测试都不够。
至少要让 Agent 用浏览器走一遍关键路径：
- 页面是否能打开。
- 控件是否能点击。
- 表单是否能提交。
- 数据是否能显示。
- 错误状态是否正常。
- 控制台有没有报错。
- 移动端有没有明显布局问题。
如果是视觉相关任务，还要截图。截图是很便宜的证据。它能帮你发现很多“命令行看不见”的问题。
Stop condition：让 Agent 知道什么时候该停
Agent 需要明确的停止条件。
常见停止点包括：
- 连续两次验证失败。
- 任务范围明显扩大。
- 需要删除、发布、改权限、花钱、触碰生产数据。
- 当前阶段超过预算。
- 遇到多个可行方案但无法判断取舍。
- 关键依赖不可用。
- 用户给的目标互相冲突。
停下来很正常。失去边界继续跑，风险更大。
一个好的 Agent 工作流，应该允许它说：“我现在需要人判断。”
Rollback path：每个阶段都要能退回
Agent 自动化越强，越需要回滚路径。
代码任务至少要有 git diff。数据任务要有 dry-run、备份、row count。发布任务要有草稿、预览、读回验证。配置任务要记录旧值。
没有回滚路径，就不要让 Agent 自动执行高影响操作。
Trace everything：把过程留下来
长任务 Agent 最怕黑箱。
至少要留下这些东西：
- 输入任务。
- 使用的模型和工具。
- 关键工具调用。
- 文件变更。
- 验证结果。
- 人工确认。
- 失败重试。
- 最终产物。
OpenAI Agents SDK 的 tracing 文档也采用了类似思路：
> 记录 agent run 中的 LLM generation、tool call、handoff、guardrail 和自定义事件，用于开发和生产环境里的调试、可视化和监控。
trace 的目的不在漂亮 dashboard，而在出问题时能回答：它为什么这么做？哪里开始偏？哪一步验证放过了问题？
Agent 的可控性，很大一部分来自可追踪性。
## 最后：Agent 的上限看模型，下限看架构
Agent 的能力上限当然来自模型。
更强的模型会写出更好的代码，会更会拆问题，会更会调用工具，也会更少犯低级错误。这个趋势不用怀疑。
可长任务进生产，不能只看上限。
它还要看下限：
状态乱了能不能恢复，计划漂了能不能拉回，验证失败能不能发现，权限风险能不能挡住，成本异常能不能停止。
ReAct 论文早就把一个方向讲清楚：
> Agent 需要在 reasoning 和 acting 之间交替，通过外部环境拿 observation，再更新计划。Reflexion 进一步强调 feedback signal 对 agent 改进的重要性，它把反馈转成语言记忆，让后续尝试能从失败里学习。
这些研究和今天的工程实践，其实指向同一件事：
Agent 的质量不只来自生成，还来自行动后的反馈。
缺状态，反馈留不住。
缺规划，反馈不知道该回到哪个阶段。
缺验证，反馈本身就是假的。
Context、Planning、Verification 已经不属于三个小技巧，它们已经是 Agent 系统最基本的控制面。
未来更强的 Agent，不会只是更像一个“自动干活的人”。
它会更像一个可审计的工程系统：
知道自己在做什么，知道做到哪里，知道怎么证明做对了，也知道什么时候该停下来找人。
我现在判断一个 Agent 工作流，会先跳过模型名。
我会先问这五个问题：
- 状态在哪里？
- 计划怎么拆？
- 执行怎么记录？
- 结果怎么验证？
- 什么时候必须停？
这五个问题回答不清，模型越强，跑偏时造成的动静越大。
回答清楚了，Agent 才真正开始从 demo 进入工程。
## 参考资料
Anthropic, Best Practices for Claude Code. 该文强调 context window 会快速填满，窗口越满性能越容易下降，并建议通过测试、截图、期望输出给 Claude 验证路径。
Anthropic, Effective harnesses for long-running agents. 该文讨论跨多个 context window 的长任务 Agent，并使用 initializer agent、coding agent、进度文件和 session handoff 来维持持续进展。
Anthropic, Harness design for long-running application development. 该文介绍 planner / generator / evaluator 三角色结构，并让 evaluator 使用 Playwright 像用户一样操作应用，验证 UI、API 和数据库状态。
Anthropic, Building effective agents. 该文将 agentic system 区分为 workflows 和 agents，并强调简单、可组合的模式通常比复杂框架更有效。
OpenAI, Agents SDK Tracing. 文档说明 tracing 会记录 LLM generation、tool call、handoff、guardrail 和自定义事件，用于调试、可视化和生产监控。
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models. 论文提出让模型交替生成 reasoning traces 和 task-specific actions，利用外部观察更新计划、处理异常。
Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning. 论文提出将反馈信号转成语言反思，并保存在 episodic memory buffer 中，用于改进后续尝试。
## 相关链接
- [烟花老师](https://x.com/teach_fireworks)
- [@teach_fireworks](https://x.com/teach_fireworks)
- [9.8K](https://x.com/teach_fireworks/status/2058929780880458125/analytics)
- [Best Practices for Claude Code](https://www.anthropic.com/engineering/claude-code-best-practices)
- [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
- [Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
- [Building effective agents](https://www.anthropic.com/research/building-effective-agents/)
- [Agents SDK Tracing](https://openai.github.io/openai-agents-python/tracing/)
- [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)
- [Reflexion: Language Agents with Verbal Reinforcement Learning](https://arxiv.org/abs/2303.11366)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:14 PM · May 25, 2026](https://x.com/teach_fireworks/status/2058929780880458125)
- [9,880 Views](https://x.com/teach_fireworks/status/2058929780880458125/analytics)
- [View quotes](https://x.com/teach_fireworks/status/2058929780880458125/quotes)
---
*导出时间: 2026/5/26 09:40:04*