X 上又在吵模型,AI编程的分水岭其实是 Harness
今天刷 X ， AI 编程圈又开始熟悉的场面：这个模型写代码更稳，那个模型更会“自己干活”，截图一张接一张，评论区像在选年度最佳球员，吵得人心累。
我不想泼冷水，但这件事有点跑偏。准确说，是吵得越来越无聊了。
当一个 Agent 只能帮你补几十行代码时，模型能力几乎就是全部。可一旦你要它连续跑几小时、改多个模块、写测试、提 PR 、碰真实环境，最大的变量忽然变成了：它有没有一条不会把自己带沟里的轨道。
这条轨道，行业里开始叫 Harness 。
模型再强，也会在“下一轮”失忆
X 上最热的讨论当然仍是模型对比：谁更会规划、谁修 bug 更利落、谁少写废话。这个比较没错，只是不够。
Anthropic 在长任务实验里把问题说得很直白： Agent 的工作是分 Session 进行的，新一轮上下文并不天然知道上一轮做了什么。于是常见两种翻车：要么一口气做太多，半截卡在上下文里；要么看到仓库里已经有些文件，就自信地宣布“完成”。Anthropic 的工程复盘[1]讲得很具体。
这个画面是不是很眼熟？
你给它一句“把登录重构一下，顺便补测试”，回来时它改了 43 个文件，测试绿了，却没告诉你它把权限边界挪到了哪儿。代码没报错，心里开始发毛。最烦的是，这不是笨——一开始我还怪模型不行，后来发现是我自己没给它留任何记号，它根本无从下手。是它在当前窗口里已经找不到“为什么当初这么设计”的证据。
模型负责生成答案， Harness 负责让它知道什么叫没做完。
别小看后半句。生产环境里，后半句往往更贵。
Harness 不是一份 2,000 行的提示词
有些团队听到 Harness ，第一反应是再写一份巨长的 AGENTS.md。架构规范、上线流程、所有历史教训，往里塞。团队午饭规则我也差点想写进去。停。写到这儿已经有点离谱了，再塞下去，这份文档自己就成了没人读的垃圾场。
OpenAI 的公开实践反而强调“可读性”：把关键知识放进版本控制、让 Agent 能在仓库内发现的地方，并把架构约束变成可执行的检查，而不是一堆祈祷式说明。其内部实验曾以全 Agent 生成代码的方式构建产品；真正支撑速度的，不是让模型自由发挥，而是明确的结构、测试和反馈回路。OpenAI 的复盘[2]值得细看。
说白了， Harness 至少有四个东西：
1.地图：项目目标、目录边界、关键命令放在仓库里，让新一轮 Agent 能快速定位。2.护栏：把“别跨层依赖”“必须写日志”“敏感操作需确认”写进 linter 、测试或权限配置。能机器检查的，别留给模型猜。3.交接本：每轮结束更新进度、遗留风险、下一步。一个progress.md 往往比再加一轮“请认真思考”有用。4.验收器：不只跑单测，还要检查用户路径、关键截图、差异摘要和失败原因。这四样不性感，甚至有点像在给一个很能干、但注意力容易漂走的实习生搭工作台。你别说，这个比喻我自己都觉得糙。应该说，是糙得有点糙，但糙得对。
就是这个意思。
先别造多 Agent 军团，做一个能被打断的闭环
现在的 X 很容易让人上头：多 Agent 并行、自动 PR 、全天候任务队列，听起来像工程团队突然多了几十个人。
可大部分个人项目和小团队，根本不缺“更多 Agent”。缺的是一次能放心交出去、也能随时叫停的任务闭环。
我建议从下面这个最小配置开始，半天就够：
任务卡：目标 / 不做什么 / 验收标准 / 最大改动范围 ↓ Agent 先读 README + AGENTS.md + 最近变更 ↓ 只实现一个可验证的小切片 ↓ 跑测试、列出改动文件、留下 progress.md ↓ 人类看 diff 后决定：合并、返工，还是拆下一张任务卡 比如“给后台加导出 CSV”这件事，别把需求写成一句话。任务卡至少补三句：
•只处理已过滤后的数据，不能改查询条件；•10 万行时不能把整个结果一次塞进内存；•需要单测，外加一次真实文件下载验证。这就不是在限制 Agent ，而是在减少信息不对称。模型选错了，最多是一轮返工；边界没写，可能就是一次悄无声息的数据事故。两种痛感，完全不一样。
什么时候该升级 Harness ？看失败模式，不看朋友圈热度
Harness 也不是越复杂越好。 Anthropic 今年的后续文章专门提醒： Harness 里编码的是对模型弱点的假设，模型变了，这些假设也会过期。他们的 Managed Agents 文章[3]说得很克制。
所以别一开始就整一套调度器、向量库、五个角色和一排看不懂的 YAML 。先记录失败，连续出现再升级。
| 你反复看到的问题 | 先补的部件 |
|---|---|
| 新会话不知道做到哪了 | progress.md + Git 提交规范 |
| 总把范围越改越大 | 任务卡的“不做什么”与改动上限 |
| 测试全绿但功能不能用 | 端到端检查或浏览器验收 |
| 同类错误一再出现 | 把 review 意见升级为 lint / test |
| 等人工回复时整条任务停住 | 拆成可独立验收的小任务 |
这里有个很土但很有效的原则：一次事故，至少留下一条机器能执行的防线。
不然你下次还是会在凌晨一点，对着“任务已完成”的提示发呆。
未来比的不是谁的模型更会写，而是谁更会搭环境
模型迭代当然还会继续，今天的榜单明天就可能换人。可 OpenAI 和 Anthropic 的公开工程经验其实指向同一件事：长任务要靠可发现的上下文、清晰的工作切片，以及可验证的反馈闭环；模型能力是必要条件，不是交付保证。OpenAI 对 Agent Harness 的架构说明[4]也把 Harness 、执行环境和应用服务明确拆开了。
所以 X 上下一次再吵“哪个模型把另一个按在地上摩擦”时，不妨先问自己一个更扫兴的问题：
我的 Agent 换个模型，明天还能知道该读什么、不能碰什么、怎么证明它真的完成了吗？
如果答案是不能，先别急着换模型。
先把轨道铺好。
参考链接
[1] Anthropic 的工程复盘: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[2] OpenAI 的复盘: https://openai.com/index/harness-engineering/
[3] 他们的 Managed Agents 文章: https://www.anthropic.com/engineering/managed-agents
[4] OpenAI 对 Agent Harness 的架构说明: https://developers.openai.com/api/docs/guides/agents-api/architecture