本文是「每周 Signal｜AI × SE」第 24 期，欢迎关注和交流～
我们关注 AI 如何真正进入软件工程，以及模型之外那些正在变得越来越重要的系统能力。
最近一周，Agent Harness 出现了一组很有意思的信号。一边，AWS、Microsoft、Pydantic 都在把 Harness 中越来越多的能力独立出来：Session、Context、Tool Execution、Sandbox、Memory、Guardrail、Sub-agent，这些过去散落在不同 Agent 产品内部的实现，正在变成可以直接使用或组合的基础能力。
另一边，资深工程师 Steve Yegge 近几年一直在探索 Coding Agent 和多 Agent 开发系统。在长期把 Agent 放进复杂项目运行之后，他在最近的 The Shape of Things to Come 中甚至提出，自己已经不再相信存在一套真正通用的 Harness。随着系统越来越复杂，任务怎么组织、不同 Agent 怎么分工、什么结果算完成、失败后如何恢复，这些机制最终都会和具体项目越来越紧密地结合。
于是就出现了一个问题：如果通用 Harness 已经越来越强，为什么落到具体项目以后，还是会长出这么多自己的东西？这些定制到底会不会一直存在？
一开始，这个问题很容易被理解成“通用”和“定制”的二选一。但继续往下看，真正值得讨论的可能并不是哪一边最终胜出，而是：哪些问题会随着通用 Agent 变强被逐渐吸收，哪些东西即使模型再强，也必须来自具体项目和组织。
在 Coding Agent 中，Harness 可以简单理解成模型外部那套让 Agent 真正工作起来的系统。模型负责推理，但一个 Agent 想连续工作几十分钟甚至几个小时，还需要解决很多模型之外的问题：怎么维持 Session，怎么管理 Context，在哪里执行 Shell，如何访问文件，什么时候压缩历史信息，失败以后怎么恢复，又允许调用哪些工具。
但今天行业里谈 Harness 时，经常还会把另一组能力一起放进来：任务如何拆解、项目知识怎么加载、什么测试通过才算完成、什么时候应该找人确认、多个 Agent 怎样协作，以及失败以后下一步应该怎么调整。
这里其实混在了一起两类不同的问题。一类是 Agent 如何稳定地运行和行动；另一类则是 Agent 如何判断下一步应该做什么，以及怎样把一个真实任务完成。
当这些都被统称为 Harness 时，“Harness 最终会不会通用”本身就很难有一个简单答案。
这一周几个动作都很典型。
AWS 的 AgentCore Harness 已经把 Agent Loop、Context、Memory、Session、Tool Execution 和隔离环境放进一套托管能力里。Microsoft 开始把 GitHub Copilot Harness 作为 Agent Framework 的执行引擎，由 Copilot 提供 Shell、文件修改和工具调用等软件工程执行能力。Pydantic 的 AI Harness 也把 Context Management、Skill、Memory、Sandbox、Guardrail、Sub-agent 等拆成可以组合的 Capability。
很多过去需要每个 Agent 团队反复实现的基础能力，正在逐渐被抽出来。一个团队以后大概率没有必要为了自己的项目重新实现一套 Session 管理、Sandbox、Checkpoint 或 Tool Runtime，而是直接使用已经成熟的通用能力。
而且这种通用化很可能不会停在 Runtime。Skill、MCP、代码检索、Browser、Sub-agent、Guardrail 这些能力，也正在越来越模块化。项目可以选择、组合和配置它们，而不是每次从头实现。
到这里，行业方向其实比较明确：越来越多 Harness 能力会成为标准件。
真正的问题是，它会停在哪里。
我们很容易把任务拆解、Context Retrieval、验证策略和 Multi-Agent 协作，都归到“项目自己的工作方式”。
但如果把时间拉长，这个判断未必成立。
今天一个复杂需求可能需要提前定义 Workflow，告诉 Agent 先做需求分析、再找代码、再拆任务、再调用多个 Agent。但模型继续变强以后，这些步骤本身很可能越来越多地由 Agent 动态完成。
给它一个需求，它可以自己分析 Repository、寻找相关文件、建立计划、拆分子任务，再根据执行结果不断调整。它也可以自己判断什么时候需要更多上下文，什么时候应该调用工具，什么时候拉起 Sub-agent，甚至根据代码 Diff 和历史测试关系，选择怎样的验证方式。
这些能力目前做得还不够可靠，所以我们会把很多流程写进 Harness。但“现在需要写进 Harness”，并不代表“未来必须由项目提供”。
Harness-R1 也说明了这种空间。研究保持目标 Agent 不变，只根据实际失败轨迹修改 Runtime Harness，仍然能够提高任务成功率。这证明模型之外的运行方式确实很重要，但另一方面，它也说明这些策略本身可以继续学习和优化，并不一定永远需要人工提前定义。
从这个角度看，通用 Agent 很可能还会继续吸收大量今天被视为 Harness Engineering 的东西。
任务怎么拆、Context 怎么找、用几个 Agent、失败后怎么重试，甚至很多情况下选择怎样的验证方式，都更像“怎么做”的问题。而“怎么做”恰恰是模型能力最有可能持续覆盖的区域。
但这里存在另一类完全不同的问题。
假设一个需求要求“给订单详情增加退款入口”，Agent 可以自己找到页面、定位接口、修改代码并补充测试。可如果系统里没有任何地方说明“只有完成实名认证且金额低于某个阈值的订单才能退款”，再强的模型也无法可靠推导出这条业务规则。
它可以猜，但无法知道猜的是不是对的。
同样，一个 Agent 可以自己决定应该多跑几个测试，却无法仅靠代码推理决定公司到底允许多大的生产风险；它可以分析一个改动可能影响哪些模块，但无法凭空知道某类数据因为合规要求绝对不能发送到外部系统。
这些问题并不是模型“还不够聪明”，而是正确答案本来就在模型之外。
它们包括来自具体项目和组织的目标、事实、约束、完成标准和责任边界：我们到底想实现什么，当前系统有哪些真实规则，哪些事情不能做，什么结果才算真正完成，以及哪些风险必须由谁来承担。
这也是“通用 Agent 能不能解决一切”真正的边界。
通用 Agent 可以越来越强地解决“怎么做”，但它无法消除外部世界对“什么是对的”的定义。
而且越是真实的软件系统，这一层越重要。代码只是其中的一部分，业务规则、历史兼容、组织流程、权限边界、质量标准和责任关系，很多时候并不会完整存在于代码里。
Steve Yegge 的 Wheelhouse 虽然是一个非常先锋、甚至有些极端的实践，但它展示出的真正价值可能也不只是“项目需要自己定制一套 Harness”。更值得注意的是，当 Agent 深入一个长期演进的复杂项目以后，越来越多属于这个项目的事实、规则和判断，需要以某种方式进入 Agent 的工作环境。
这样再回头看“通用 Harness 和项目定制”的矛盾，答案就发生了一些变化。
未来需要项目自己维护的东西，未必是越来越复杂的 Agent Framework，也未必是固定的 Task Planning、Context Strategy 或 Multi-Agent Workflow。这些方法性的能力，很可能随着模型和通用 Harness 继续进步，被逐渐吸收。
真正不会因为模型升级自动出现的，是来自具体项目和组织的目标、事实、约束、完成标准和责任边界。
问题因此也从：
我们应该怎样教 Agent 完成这个项目？
逐渐变成：
怎样让 Agent 知道，在我们的系统里什么才是正确的？
这背后需要沉淀的东西可能会以很多形式存在：Repository 中可读取的工程约束、结构化的业务知识、明确的接口和契约、可以自动执行的测试与 Eval、Policy、Quality Gate，以及必要时由人提供的关键判断。
它们未必都要被写进一个所谓的 Application Harness，也未必都需要重新实现。真正重要的是，这些项目特有的语义能够被 Agent 获取、理解，并最终被验证。
所以，如果通用 Harness 继续变强，我现在更关心的已经不是“团队还需要自己定制多少 Harness”，而是另一件事：
当“怎么做”越来越可以交给通用 Agent，我们有没有把“什么是对的”定义清楚？
这可能才是项目长期真正需要沉淀的东西。
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
