这两个月我越来越确定一件事：Agent 赛道真正拉开差距的地方，已经不是“模型会不会写代码”，而是你怎么把模型放进一个能持续工作的执行框架里。

很多人到现在还把长任务 Agent 理解成“更长的 Prompt + 更多工具”。这个理解在做 demo 时还能凑合，一旦任务跨文件、跨步骤、跨小时，问题就会立刻暴露：上下文变脏、任务跑偏、自评失真、失败后无法恢复，最后看起来像是模型不够强，实际上常常是 harness 太弱。

Anthropic 在 2026 年 3 月关于长时应用开发的工程文章里，把这件事说得很直白：他们为了让 Agent 做更长时间的软件开发，不是只加提示词，而是设计了 planner、generator、evaluator 这类分工结构，并用文件化交接来维持多阶段工作的一致性。更关键的是，他们明确指出，长任务里常见的问题并不只是“上下文不够”，还包括模型在长上下文下会提前收工、对自己产出的判断过于宽松、以及复杂任务在时间拉长后逐渐失去连贯性。

为什么 Harness 会成为分水岭

原因很简单。短任务里，模型像一个会说话的函数；长任务里，模型更像一个会犯错、会遗忘、会误判、也会半途“自我感动”的临时工。你不给它搭建工作制度，它就不可能稳定地产出结果。

所以所谓 harness，本质上不是“把 API 再包一层”，而是一套工作制度。它至少要回答这些问题：任务如何拆分；当前阶段的完成标准是什么；失败后如何回滚或重试；谁负责执行，谁负责验收；跨 session 的状态如何交接；工具权限如何控制；日志如何保留。

这也是为什么我现在越来越不相信那些只展示单轮效果的 Agent 演示。单轮能跑通，不代表可交付。真正接近生产的系统，应该让你看到它如何拆任务、如何验收、如何恢复，以及在失败时怎么不中断整个工作流。

对开发者真正有价值的，不是“全自动”，而是“可控自动化”

很多宣传喜欢把长任务 Agent 说成“把需求丢进去，睡一觉起来就有产品”。这类说法最容易误导独立开发者。因为你真正需要的，通常不是一个会连续 6 小时自由发挥的模型，而是一个能在你设定边界内持续推进的系统。

比如，你可以让 planner 负责把模糊需求扩成任务清单；让 generator 一次只做一个 sprint；再让 evaluator 用 Playwright 或测试脚本去验收。这样做的核心收益，不是让模型“更聪明”，而是让系统在出错时更容易定位责任。到底是需求没说清，还是执行偏了，还是验收太松，能拆得清楚，后续就能优化。

从工程角度看，这比追求一个万能 Agent 现实得多。因为可维护系统的前提不是它永远不犯错，而是它犯错之后你知道该修哪一层。

独立开发者现在该怎么投入

我的判断很明确：值得重度关注，但不值得一上来就重资产自研一整套 Agent 平台。

如果你是独立开发者，现阶段最划算的投入方式不是造“大而全”的框架，而是先把自己高频、重复、可验收的任务流程化。比如代码迁移、文档整理、批量修复、测试回归、内容生成后的校验。这些任务都有共同特征：边界相对清楚，可以拆阶段，也容易加验收点。你先把 harness 思维用在这些地方，比追热点更有回报。

反过来说，如果你的任务本身目标模糊、成功标准不清、执行路径高度依赖人类判断，那就别急着上长任务 Agent。那不是模型不行，而是任务还没被工程化。

结论

2026 年值得认真学的，不再只是“怎么写更好的提示词”，而是怎么给模型设计一个能长期工作的制度。Harness 不是边角料，它正在变成 Agent 产品力的主战场。谁能把任务拆分、状态管理、评估、恢复和权限边界做扎实，谁才更接近真正可交付的 Agent。

所以我的建议是：把“模型能力”降级成输入条件，把“harness 设计”升级成核心能力。以后开发者之间的差距，很可能就出在这里。