过去一年，开发者讨论 agent 时常常先问模型：哪个模型更会写代码，哪个模型工具调用更稳，哪个模型上下文更长。这个问题仍然重要，但已经不够了。
今天的热点源给了一个很清晰的信号：Evo-Bench 评测模型能否改进 agent harness，A2E 评测 harness 的端到端执行轨迹，GitAgent 试图把 agent 定义标准化为 Git 仓库中的文件。三个方向表面不同，本质上都在回答同一个问题：当模型能力接近时，agent 系统靠什么拉开差距？
答案越来越像传统软件工程：执行层、协议、状态、审计、回归测试、版本控制。
模型不是 Agent 的全部
一个生产 agent 至少包含这些部分：
任务入口：用户请求、队列、事件、工单
上下文层：文件、记忆、检索、历史轨迹
规划层：目标拆解、步骤选择、退出条件
工具层：API、shell、浏览器、数据库、内部服务
状态层：中间结果、重试记录、锁、事务
安全层：权限、审批、敏感信息过滤
审计层：trace、日志、指标、回放
发布层：eval、灰度、回滚、版本管理模型只是规划层和语言推理的一部分。很多失败不是模型“笨”，而是 harness 没给它稳定边界：工具 schema 模糊、错误不可恢复、上下文塞满无关文件、记忆冲突、日志不可回放。
这解释了为什么同一个强模型在不同产品里表现差异很大。有的 coding agent 能稳稳完成跨文件修改，有的只会生成看似正确的 patch；有的 office agent 能处理表格状态，有的会在第三步忘记筛选条件。差距经常出在模型外面。
Evo-Bench 把 Harness 进化变成评测对象
Evo-Bench 的论文摘要指出，标准 agent 评测多停留在静态任务求解，而新问题是 harness evolution：agent 能否自主优化自己的操作框架。论文把评测放在 Search、Office、General 等领域，并尝试隔离基础模型能力和框架改进能力。
这件事很关键。过去我们常把 agent 自改进理解成“模型写更好的 prompt”。但 harness 进化范围更大：
改工具调用顺序
改任务拆解模板
改检索策略
改中间状态保存方式
改失败重试条件
改输出检查器
改权限升级路径如果这些修改能被模型提出、执行、验证和迁移，那么 agent 就不只是任务执行器，而开始像一个会改进自身工作台的系统。
不过 Evo-Bench 也提醒我们，进化收益有领域差异。Search 类任务更容易通过通用策略提升，Office 类任务往往需要具体流程。这个结论非常符合工程直觉：搜索任务可以靠更好的查询、比较和证据整理提升；办公任务却经常卡在表格格式、字段含义、权限、文件版本、企业流程细节。
A2E 让过程变成一等指标
如果 harness 会进化，就必须能审计。否则你不知道它到底变好了，还是只是绕过了测试。
A2E 的方向是端到端 agent auditing。它用标准任务协议和执行轨迹来评估效率、工具使用、规划和错误恢复。这个角度比单一正确率更接近生产需求。
一个 agent 的最终答案正确，不代表过程安全。它可能读了过多文件，调用了不必要的外部 API，在失败后重复执行同一危险动作，或者靠异常长上下文硬扛。对于个人项目这只是浪费，对于企业系统就是事故前兆。
因此下一代 agent harness 应该默认输出这些指标：
每任务工具调用次数
每任务总 token 和 wall time
失败后是否改变策略
是否违反工具白名单
是否访问敏感路径
是否产生可复现证据
是否通过输出检查器没有这些指标，harness 进化就是黑盒调参。
GitAgent 代表可移植定义的需求
GitAgent 在 HN 的讨论点是把 agent 定义成 Git 仓库里的文件：agent.yaml、SOUL.md、SKILL.md、规则、记忆、工具、hooks。这个方案未必会成为唯一标准，但它抓住了一个真实痛点：agent 定义正在被不同框架锁死。
今天一个团队可能同时用 Claude Code、OpenAI Agents SDK、LangGraph、CrewAI、自研 workflow。每个框架都有自己的工具注册、记忆格式、提示组织和生命周期。迁移一次 agent，常常等于重写一次。
Git-native 的优势是工程团队已经会治理它：
agent 行为可以 code review
规则修改可以走 pull request
记忆变化可以看 diff
实验版本可以开 branch
坏版本可以回滚
发布可以打 tag这不意味着所有记忆都应该进 Git。高频动态状态、敏感数据、用户隐私不适合直接提交。但 agent 的身份、规则、工具声明、技能和测试集，非常适合版本化。
Harness 会成为新的平台层
如果把 agent 系统拆开看，模型像 CPU，harness 像操作系统和运行时。CPU 更快当然重要，但应用体验也取决于调度、内存、权限、文件系统、驱动和日志。
Agent harness 的平台层会包括：
任务协议：不同任务如何声明输入、权限和成功标准
工具协议：工具 schema、权限、超时、返回值和幂等性
记忆协议：长期记忆如何写入、检索、删除和审计
轨迹协议：执行过程如何记录、压缩、回放和对比
评测协议：如何固定任务集、防止过拟合、做发布门禁
迁移协议：一个 agent 如何跨框架导出和导入谁掌握这层，谁就能更快换模型、更稳上线、更低成本运营。反过来，如果 harness 完全散落在业务代码里，模型升级会变成一次又一次脆弱迁移。
企业落地的优先级
第一，不要急着让 agent 自改。先让 agent 可测。固定 30 到 100 个代表性任务，记录当前模型和 harness 的基线。
第二，不要让工具权限跟着模型能力自动扩张。工具层应该有独立策略：只读、可写、需审批、高风险拒绝。
第三，把 agent 定义从应用代码里抽出来。哪怕不用 GitAgent，也应该有清晰目录保存模型配置、系统规则、工具列表、技能、eval 和变更记录。
第四，建立轨迹差分。每次改 prompt 或工具 schema，不只看最终成功率，还要看工具调用次数、失败类型、成本、敏感访问和输出证据。
第五，让自进化先发生在离线环境。模型可以提出 harness patch，但 patch 必须跑回归任务，必须有人或自动门禁决定是否合入。
开发者应该怎么准备
如果你现在还在用一个大 prompt 加几个函数调用，可以先做三件小事。
先定义任务协议。每个任务都写清目标、输入、允许工具、风险等级、成功标准。
再包工具代理层。模型只能请求工具，不能直接执行工具。每次请求都记录参数、返回、耗时、错误。
最后保存执行轨迹。用 NDJSON 就够了。后续你可以把轨迹送进 A2E 类报告，也可以让模型根据失败轨迹提出 harness 改进。
这三件事完成后，你的 agent 就从“脚本”变成“系统”。系统才谈得上进化。
结论
Agent 的下一轮竞争不会只发生在模型榜单上。模型仍然是上限，但 harness 决定能否把上限转化为稳定生产力。
Evo-Bench 告诉我们 harness 自进化值得评测，A2E 告诉我们执行过程必须可审计，GitAgent 告诉我们 agent 定义需要可迁移、可 review、可回滚。把这三件事放在一起看，趋势已经很明确：未来优秀的 agent 团队，不只是会选模型的团队，而是会设计运行时的团队。