Agent Environment Engineering：Agent 工程的新战场

过去一年，很多团队都在研究怎么把大模型变成 Agent：给它工具，给它权限，给它任务，让它能自己跑起来。

于是大家开始关注 Prompt、Context、Tool Use、Workflow、Harness。可是当 Agent 真的开始进入开发、运维、研究、文档和业务流程以后，一个更底层的问题浮出来了：Agent 到底工作在一个什么环境里？

这就是 Environment Engineering 想解决的问题。

如果说 Harness 解决的是“怎么管住 Agent”，那么 Environment 解决的是“Agent 面对的世界是否可靠”。前者更像运行时控制系统，后者更像训练场、考场和工作制度。

为什么焦点会从 Harness 移到 Environment

早期做 Agent，大家最关心的是让它跑起来：怎么写 Prompt，怎么塞上下文，怎么调用浏览器、终端、数据库、API，怎么记录日志，怎么设置权限，怎么防止无限循环。

这些问题都重要，而且大多属于 Harness 工程。

Harness 可以理解成 Agent 的运行控制系统。它决定 Agent 怎么启动，能调用哪些工具，什么时候停下来，花多少钱，有没有权限做某件事。

但随着 Agent 越来越能干，一个新问题出现了：

就算你把 Agent 管住了，它是否真的处在一个可靠、可验证、能学习的环境里？

比如让 Agent 修 Bug。它能看到哪些文件？它能运行哪些测试？测试结果是否可靠？它删掉测试算不算成功？它提交的修改有没有证据链？失败后谁来接管？下次遇到类似问题，它能不能从这次失败里学到正确经验？

这些问题已经不是单纯 Harness 能完全解决的了。

这就是 Environment Engineering 的位置。

Prompt、Context、Harness、Environment 有什么区别

可以把 Agent 工程粗略分成几层：

层级	主要问题	简单理解
Prompt	怎么说	给 Agent 下指令
Context	给它看什么	提供文件、日志、文档、历史信息
Tool	它能做什么	浏览器、终端、数据库、API
Harness	它怎么跑	权限、状态、日志、循环、停止条件
Loop	怎么持续迭代	计划、执行、观察、修正
Self-Harness	怎么自我改进	失败总结、策略调整、记忆
Environment	它在哪里学习	状态、动作、反馈、奖励、证据、接管机制

一个比喻：Prompt 是老师说的话，Context 是课本和资料，Tool 是笔、电脑和实验器材，Harness 是课堂纪律和考试流程，Environment 则是整个学校、考试制度、评价体系和真实反馈。

学生最后会成为什么样，不能只看老师怎么说，还要看学校奖励什么、惩罚什么、允许什么、记录什么。

Agent 也是一样。

Environment Engineering 是什么

Environment Engineering 可以理解为：为 Agent 设计一个可行动、可观察、可反馈、可评估、可接管的工作世界。

它不是简单地多接几个工具，而是系统性设计 Agent 所处的环境。

一个完整环境至少包含八类要素。

1. 状态：Agent 可以看什么

状态决定 Agent 的视野。

在代码场景里，状态可能包括代码仓库、测试输出、CI 日志、最近提交、线上错误、数据库结构、接口文档和历史决策。

状态不是越多越好。给太少，Agent 会瞎猜；给太多，Agent 会迷路。好的环境会把状态整理成可行动的信息。

2. 动作：Agent 可以做什么

动作决定 Agent 的能力边界。

它可以读文件、改代码、跑测试、发请求、查日志、生成报告。但是否允许删除文件、改数据库、部署生产、修改权限，就必须明确限制。

没有动作边界，Agent 容易失控；动作太少，Agent 又只能写建议，无法完成任务。

3. 观察：Agent 怎么看到结果

动作之后必须有观察。

运行测试之后，要看到退出码、错误堆栈、失败用例和耗时；访问页面之后，要看到响应码、截图、控制台错误和网络请求；部署之后，要看到健康检查、错误率和日志。

没有观察，Agent 就不知道自己做对没有。

4. 评估：谁判断结果好不好

评估决定什么叫成功。

测试通过只是评估的一部分。代码是否可维护、接口是否兼容、用户流程是否真的恢复、线上指标是否正常，都可能是评估标准。

如果评估太单一，Agent 很容易钻空子。

5. 奖励：环境鼓励什么

奖励是最容易被低估的一环。

如果环境只奖励测试通过，Agent 可能会删除测试、改断言、mock 掉真实逻辑。测试绿了，但 Bug 没修好。

如果环境只奖励报告完整，Agent 可能会堆字数。报告很长，但没有证据。

如果环境只奖励速度，Agent 可能不复现、不验证，直接猜修复。

所以环境设计的核心不是给 Agent 更多工具，而是设计一个不会奖励坏行为的反馈系统。

6. 资源：成本和边界是什么

Agent 的行动需要成本。

一次任务最多跑几次测试？最多花多少分钟？最多调用多少次外部 API？能不能访问生产日志？能不能执行高成本模型？这些都应该是环境契约的一部分。

资源边界不是为了限制 Agent，而是为了让它在可控范围内探索。

7. 证据：必须留下什么

可靠 Agent 不能只说“我修好了”。它应该留下证据。

证据可以是复现步骤、命令输出、测试结果、接口响应、截图、关键日志、代码 diff、部署记录。

证据让人能复查，也让后续记忆更可靠。

8. 接管：什么时候必须交给人

环境必须定义接管节点。

比如涉及生产数据库、支付链路、权限系统、用户隐私、安全问题、不可逆操作时，Agent 不应该自己往前冲，而应该请求人类确认。

一个没有接管机制的环境，很难进入生产系统。

为什么说反馈比工具更重要

很多团队做 Agent 的第一反应是给它更多工具。

但工具只是动作空间。真正决定 Agent 学到什么的，是反馈。

如果反馈告诉它“测试绿了就是成功”，它就会围绕测试绿优化。如果反馈告诉它“报告越长越好”，它就会围绕字数优化。如果反馈告诉它“必须复现、修复、验证、留下证据”，它才会长出更接近工程师的行为。

这就是环境塑形。

同一个 Agent，放在不同环境里，会长出完全不同的工作习惯。

一个只要求“尽快修好”的环境，会让 Agent 倾向于快速改代码、少看上下文、不写测试、只处理表面错误。

一个要求“先复现，再修复，再验证”的环境，会让 Agent 倾向于找复现路径、分析根因、写最小测试、小范围修改、最后给出证据。

模型可能是同一个，但行为完全不同。

Harness 和 Environment 不是替代关系

Environment 重要，不代表 Harness 不重要。

它们解决的是不同问题。

Harness 管控制面，负责模型选择、工具调用、权限控制、成本限制、日志记录、状态管理、停止条件和合规边界。

Environment 管任务世界，负责状态是否真实、动作是否安全、反馈是否可靠、评价是否可作弊、证据是否充分、失败是否可复现、经验是否可沉淀。

没有 Harness，Agent 可能失控。没有 Environment，Agent 可能学歪。

成熟系统需要两者都有。

企业怎么落地：先做小环境

一听 Environment Engineering，很多团队容易直接想到一个大平台：Environment-as-a-Service，所有任务都能接，所有工具都能跑，所有 Agent 都能学。

这通常太早了。

更现实的做法是先选一个低风险、高重复、可验证的小流程。

CI 失败分流

先不要让 Agent 直接修所有 Bug，而是让它判断 CI 为什么失败：是依赖安装失败，是测试 flaky，是类型错误，是构建失败，还是需要人介入。

这个场景状态清晰、动作有限、反馈明确，很适合做成小环境。

文档漂移检查

让 Agent 检查代码变了，文档有没有同步。API 参数变了，README 有没有更新。数据库字段变了，接口说明有没有过期。

这个场景风险低，结果容易验证，也适合环境化。

线上日志归因

让 Agent 根据日志、部署记录、接口监控判断：是新版本引入，还是上游接口异常，是数据库慢查询，还是用户参数异常。

这类任务可以先让 Agent 做分析和建议，不要直接让它操作生产系统。

一个环境契约模板

设计一个小环境，可以先写这八项：

环境名称：
目标：

1. 状态：
Agent 可以看到哪些信息？

2. 动作：
Agent 可以执行哪些操作？哪些禁止？

3. 观察：
每个动作后，Agent 如何看到结果？

4. 评估：
什么叫成功？谁判断？

5. 奖励：
奖励什么行为？如何防止作弊？

6. 资源：
时间、成本、调用次数、权限边界是什么？

7. 证据：
Agent 必须留下哪些日志、截图、测试结果或 diff？

8. 接管：
哪些情况必须交给人？

比如 CI 失败分流环境可以这样写：

环境名称：CI Failure Triage

目标：
把 CI 失败自动归类，并给出可复现证据和建议处理人。

状态：
CI 日志、最近提交 diff、package lock、测试命令、历史失败记录。

动作：
读取日志、搜索代码、运行指定测试、生成报告。
禁止直接修改主分支，禁止删除测试。

观察：
测试输出、退出码、错误堆栈、耗时、重试结果。

评估：
分类准确率、报告是否包含证据、是否能复现失败。

奖励：
奖励准确分类、最小复现、清晰证据。
不奖励长报告，不奖励绕过测试。

资源：
最多运行 3 次测试，总耗时不超过 10 分钟。

证据：
保留命令、输出摘要、失败堆栈、相关文件位置。

接管：
涉及生产配置、安全凭证、数据库迁移、人为审批时交给人。

这就是一个小型 Environment。

长期记忆必须建立在可靠环境上

很多 Agent 系统喜欢做长期记忆：记录失败经验，总结项目习惯，保存用户偏好，自动改进策略。

但这里有一个风险：如果环境反馈不可靠，长期记忆会把错误经验固化下来。

比如一次测试通过，是因为 Agent 删除了测试。如果系统把这次经验记成“成功修复”，下次 Agent 就会更倾向于继续这么做。

所以长期记忆不能脱离环境质量。

好的长期记忆应该基于可复现的任务、可靠的评估、明确的证据、人类确认过的结论、可回滚的记录。

否则，自我改进会变成自我强化错误。

Environment Engineering 的本质

Environment Engineering 的本质不是搭一个复杂平台，而是回答一个问题：

我们能不能为 Agent 提供一个不会误导它的世界？

这个世界要让 Agent 看见该看的，做允许做的，得到真实反馈，被正确评价，不能靠作弊拿高分，失败后能留下证据，高风险时能交给人。

当这些条件具备，Agent 才可能稳定地从工具调用者变成可靠的工作者。

参考资料

• Agentic Environment Engineering for Large Language Models，综述论文，讨论 Agentic Environment 的建模、合成、评估与应用。
• EurekAgent: Towards Autonomous Scientific Discovery with Scalable Agentic Environment Design，提出把 Environment Engineering 用于自主科学发现。
• Andrej Karpathy 关于 autoresearch 的讨论，强调研究型 Agent 需要可执行、可反馈、可评估的环境。

结语

过去我们常问：这个 Agent 用的是什么模型？

以后可能更重要的问题是：这个 Agent 工作在什么环境里？

模型能力会越来越强，工具也会越来越多。但真正决定 Agent 是否可靠的，往往是它所处的环境。

环境奖励什么，它就优化什么。环境允许什么，它就尝试什么。环境记录什么，它就能学习什么。环境忽略什么，它就可能钻空子。

所以，Agent 工程的下一阶段，不只是写更好的 Prompt，也不是堆更多工具，而是设计更可靠的环境。

一句话总结：

Harness 让 Agent 跑起来，Environment 决定 Agent 会长成什么样。