硅谷传来一种截然不同的声音——Harness 将死，未来属于 environment engineering，啥意思，为什么
这篇文章的重量不在于“又一个新词”，而在于它把 Agent 工程里最容易自嗨的部分，硬生生拆成了两类工作：一类会被模型厂 API 吞掉；另一类不会。你站错位置，努力越多越像在给别人修路。
硅谷传来的那句狠话——“Harness 将死，未来属于 environment engineering”——如果只当口号听，会误导你把方向盘扔掉；但如果当成路线图，它其实是在说：别再把机制当壁垒，把环境当成你能撬动的长期杠杆。
先把三个词摆正：从咒语到控制层，再到改造世界
这两年 AI 圈的概念更新，像是一种通词膨胀。
- 最早我们迷信 prompt engineering：找一句咒语，让模型“点石成金”。
- 然后到了 context engineering：不是一句话，而是给它恰到好处的上下文。
- 再后来是 harness / harness engineering：不仅是上下文，还包括工具调用、进程管理、重试、验证、长任务运行机制——让 agent 真的能跑起来、跑得久一点、成功率高一点。
- 现在开始有人喊 environment engineering：别再训练司机了，先修路；把环境接口变成 agent 友好的结构化世界。
这不是学术争论。它在问一个更现实的问题：在 AI Native 时代，你到底该把团队的时间投在哪里，才不会被下一次 API 更新抹平？
为什么会有人说 “Harness 将死”：模型厂正在吞噬“机制”
对 harness 的唱衰并非空穴来风。原因很简单：底层模型正在基建化。
过去你要写几百行的编排逻辑来实现：
- 重试与容错
- JSON 输出约束
- 长上下文压缩
- 工具调用循环
- 推理长度控制
今天很多都变成 API 的几个参数：结构化输出、上下文缓存、原生工具调用、推理控制……当这些能力被下沉成“水电煤”，那些只封装了 prompt 链与基础执行循环的套壳框架，会被降维打击，这是客观趋势。
于是你会看到一个危险的诱惑：既然机制会被吞掉，那我们干脆放弃自研控制层，把所有希望押在更强的模型上。
这就是那句“harness 将死”最容易被误读的地方。
Environment engineering 的诱惑：修路的杠杆，往往大于训练司机
environment engineering 的魅力在于杠杆率。
Anthropic 的实验直觉很强：把 Claude 放在一个高度结构化的数字环境里，工具 API 的边界清晰、输入输出严格定义，结果 agent 的表现显著好于在真实终端那种混乱环境中的发挥。
这揭示了一个常被忽略的事实：很多时候 agent 表现不佳，不是“脑子不够好”，而是“世界太难懂”。
你可以把它理解成两条投资路线：
- harness engineering：训练司机、加装辅助驾驶、改驾驶习惯
- environment engineering：修路、统一交通标识、把坑填平、让车道线可见
在很多数字化场景里，修路确实比训练司机更值钱。MCP、Claude Code 之类实践也在证明：只要环境接口足够结构化，模型不需要你写一堆复杂的编排逻辑，也能表现惊人。
于是“未来属于 environment engineering”听起来像一个更高维、更长期的答案。
但问题是：商业世界不按理想环境运行。
关键反转：API 会吞噬机制，但替代不了策略
把 harness 视为“终将被吞掉的中间件”，只对了一半。
现实世界有一条铁律：大语言模型是概率系统，而商业世界要确定性结果。
企业要的不只是“能跑”，而是：
- 可观测性与可审计：为什么这么决策？链路能否回溯？
- 成本与路由网关：如何在多个模型之间动态路由，既聪明又省钱？
- 系统级容错：当 API 不稳定、模型产生幻觉时，如何确定性干预并闭环？
- 合规与安全：在行业约束里如何保证输出可用、可控、可追责？
这些不是“机制”，是“策略”。
机制可以下沉为 API 参数：工具怎么调用、缓存怎么开、格式怎么约束、基础循环怎么跑。 但策略无法外包：什么时候降级、如何切分任务、冲突时听谁的、在哪些环节必须验证、如何把风险锁在沙箱里。
所以 harness 的本质从来不只是“封装逻辑的中间件”，而是复杂系统的控制平面：方向盘、刹车、安全气囊。
它不会死，它只是在从“写机制”迁移到“写策略”。
那为什么环境工程又被吹成终局：因为环境会产出数据飞轮
如果把时间拉长，environment engineering 的确更像终局之战。
当你真正把模型与控制层嵌入到真实业务环境，并重构了交互接口，你会获得两样东西：
- 你拥有了环境：操作面、权限边界、事件流与反馈回路
- 你拥有了数据：每一次采纳、修改、纠错、失败轨迹，都会形成闭环数据
这些数据反过来不仅能优化 harness 的策略，还能优化模型与工具结构，从而形成自我进化的正循环。Microsoft 365 Copilot 这类例子之所以强，不是因为它“会总结”，而是它掌控了办公世界的环境接口与数据流。
这就是 environment engineering 真正的壁垒：不是接口优雅，而是“把真实世界变成可学习的环境”。
但别幻想捷径：环境工程撞上的，是遗留系统与隐性知识
环境工程在企业落地上有明显局限，它不是你想做就能做。
传统商业场景里，“环境”往往由三类东西组成：
- 运行了十几二十年、文档不全的遗留系统
- 散落在邮件、长文本、Excel 里的非结构化信息
- 人类专家的隐性知识与直觉判断
把这堆东西重构成 agent 友好的 API，成本高到足以劝退客户与工程师。更现实的是：绝大多数企业不会为了让 agent 跑得顺，就重构耗资千万、运行十年的核心系统。
所以环境工程更多是长期目标，而不是短期可走的捷径。大多数时候，不是世界适应 agent，而是 agent 必须学会在噪音、混乱与非结构化里生存。
这会把聚光灯重新拉回 harness：当环境不可改时，控制平面就是你唯一的杠杆。
三阶段世界观：你现在该押哪一段价值链
文章给了一个很有用的时间结构：
- 第一阶段（模型为王）：模型更新抹平应用层探索
- 第二阶段（harness 为王）：模型趋稳后，企业级可用的瓶颈转向成功率、成本与安全，控制层成为乘数
- 第三阶段（数据与环境为王）：当模型与 harness 都趋于标准化，终局壁垒来自环境接口 + 闭环数据
这套世界观的价值在于：它提醒你别在注定会下沉的地方建壁垒，但也别被“未来属于环境工程”的口号拖着跑偏——你得先在第二阶段站稳，才有资格撬动第三阶段。
终极拷问：你在写机制，还是在建控制平面；你在修路，还是在画概念图？
如果你的团队还在把大量时间耗在手写基础 prompt、基础记忆存储、基础重试机制上，你大概率是在给模型厂做义务劳动。把这些交给 API，把精力转向策略层。
如果你能深耕一个真实场景，把环境接口重构成可交互、可验证、可回滚的结构化世界，并让用户的采纳与修正形成数据闭环，那你才是在提前押注终局。
所以真正的问题不是“harness 会不会死”，而是：
当 API 吞噬机制之后，你剩下的是策略能力，还是空壳？当你谈环境工程时，你掌控的是环境，还是 PPT？