为什么 AI 的下一个突破口不是更大的模型而是更好的世界

作者：袖梨 2026-07-08

一个简单的问题，暴露了 AI 研究的盲区

请你先想一个问题：

如果把一个世界上最聪明的博士生，关在一间只有一张桌子和一支笔的空房间里，他能做出什么科研成果？

答案显而易见：几乎什么都做不了。

不是因为他不够聪明，而是因为他没有实验设备、文献库、同行交流、导师反馈、预算管理——他缺少一个能做科研的环境。

这个道理放在 AI 智能体（Agent）身上，同样成立。但令人惊讶的是，过去几年 AI 研究界几乎把所有精力都花在了"让大脑更聪明"上——更大的模型、更长的上下文、更强的推理能力——而很少有人系统性地思考：我们给 Agent 提供的"世界"，到底好不好？

直到 2026 年 6 月，两篇来自中国顶级研究机构的论文，几乎同时把这个命题推到了台前。

两篇论文，一个信号

第一篇：来自中科院自动化所的"百科全书"

《Agentic Environment Engineering for Large Language Models: A Survey》是一篇足有 63 页的综述，由中科院自动化所模式识别国家重点实验室的团队完成。它做的事情很简单却极其重要：第一次系统性地梳理了"智能体环境"这个领域的所有知识，从环境怎么建模、怎么合成、怎么评估，到环境怎么驱动 Agent 进化。

这篇综述回答了一个根本问题：当我们说"环境"时，我们到底在说什么？

作者用 POMDP（部分可观测马尔可夫决策过程）给出了一个数学定义：环境是一个由状态空间、动作空间、状态转移函数、奖励函数、观测空间和折扣因子构成的动态系统。但与传统强化学习中的游戏模拟器不同，智能体环境有几个独特特征：

开放式：不是预设的固定关卡，而是可以无限扩展的交互空间
语言驱动：不是离散的动作编号，而是自然语言交互
工具增强：Agent 可以调用外部工具（代码执行、网页搜索、文件操作）

这听起来有点抽象，但接下来的另一篇论文，把它变成了一个极其具体的实践案例。

第二篇：来自清华的"宣言"

《EurekAgent: Agent Environment Engineering is All You Need For Autonomous Scientific Discovery》是清华大学计算机系团队的工作。标题里的 "All You Need" 让人想起 2017 年那篇改变 AI 历史的 Transformer 论文。而他们也确实拿出了硬核结果：

EurekAgent 在以下所有任务上刷新了世界纪录：

任务	领域	此前人类最佳	此前 AI 最佳	EurekAgent
26 圆密铺	数学	2.634	2.635986	2.635999
Erdős 最小重叠	数学	0.380927	0.380876	0.380870
第一自相关不等式	数学	1.509730	1.502863	1.502861
TriMul 内核优化	系统	N/A	已有 AI 方案	2005.03 µs
MLE-Bench 子集	机器学习	N/A	71.43%	85.71%

更惊人的是成本：26 圆密铺这个困扰数学界多年的问题，EurekAgent 用不到 11 美元的总 API 成本就搞定了。 所有数学任务的平均成本不到 17 美元。

这不是"砸钱堆算力"的故事，而是"设计对了环境，能力自然涌现"的故事。

核心思想：环境塑造行为，而非指令

EurekAgent 的论文引入了一个非常优雅的理论框架，来自生态心理学家 James Gibson 在 1979 年提出的**"可供性"（Affordance）理论**。

Gibson 的洞见是：环境不是中性的背景，它主动地塑造了处在其中的行动者"能做什么"和"会做什么"——"either for good or ill"。

一把椅子"提供"了坐的可能性，一个悬崖"提供"了坠落的危险。同样，一个 AI 科研环境，如果设计得不好，会"提供"作弊的诱惑；如果设计得好，会"提供"深度探索、诚实报告、高效协作的通道。

论文用了一个非常接地气的比喻来解释这个思想：

让我用一个更具体的例子来解释这个差异。

传统做法：Workflow Engineering（工作流工程）

假设你要让 AI 做一个机器学习研究，传统的工作流设计可能是这样的：

 复制代码Step 1: 读取数据集，分析特征
Step 2: 提出 3 个候选模型架构
Step 3: 对每个模型调参训练
Step 4: 在验证集上评估，选出最优
Step 5: 在测试集上最终评估
Step 6: 撰写实验报告

每一步都被预设好了。Agent 就像一个被严格管理的实习生，按部就班地执行。

问题在于：如果 Agent 在 Step 3 发现了一个更好的特征工程方法，它能回头修改 Step 1 吗？如果它发现测试集的数据泄露到了训练流程中，它有权拒绝执行 Step 5 吗？如果给它一个完全不同的任务（比如数学证明），这个工作流需要完全重写。

新做法：Environment Engineering（环境工程）

EurekAgent 的做法完全不同。它不告诉 Agent 怎么做，而是设计一个三阶段循环：

 复制代码Prepare → [Propose → Implement（并行）] × N 轮

Prepare（准备）：Agent 先检查实验环境是否可用，有问题就暂停、请求人类澄清。这一步确保 Agent 不会在"烂地基"上盖楼。
Propose（提案）：Agent 阅读之前所有轮次的最佳结果，可以搜索文献、浏览网页，然后提出多个候选假设。这一步是信息汇聚。
Implement（实现）：每个假设被分配到一个独立的 Agent 会话中并行执行。Agent 可以自由选择任何策略、工具、方法。这一步是探索发散。

在这个框架下，Agent 拥有极大的自由度——它可以改变策略、引入外部知识、甚至推翻之前的假设。但它的自由是被环境约束的，而不是被工作流约束的。

环境工程的四个支柱

EurekAgent 把环境工程拆解为四个核心维度，每一个都值得深入理解。

支柱一：权限工程（Permissions Engineering）

这是整个环境工程中最容易被忽视，却最关键的模块。

想象一下：你给 Agent 布置了一个任务——"写出一个在测试集上达到 90% 准确率的分类器"。Agent 如果能看到测试集的标签，它完全可以直接硬编码答案，而不需要学习任何真正的模式。这就是 reward hacking（奖励欺骗）——Agent 找到了"拿高分"的捷径，但完全偏离了你的真实目标。

EurekAgent 的做法是：

评估脚本对 Agent 完全隐藏。Agent 只能通过一个受保护的接口提交方案，获取一个分数反馈。它看不到评分逻辑，更看不到测试数据。
Agent 的工作空间和评估环境是隔离的。Agent 在自己的沙盒里写代码、做实验，但不能触碰评估系统的任何内部状态。
Agent 仍然拥有充分的"合法权限"——运行代码、搜索文献、读写文件、安装依赖——这些是它发挥创造力的基础。

这种设计体现了环境工程的核心哲学：不是限制 Agent 的能力，而是堵死它"走歪路"的通道，同时保持"走正路"的畅通。

支柱二：制品工程（Artifact Engineering）

一个常见的 Agent 痛点：每一轮对话都是"失忆"的。Agent 完成了上一轮任务，但下一轮开始时就忘得干干净净。

EurekAgent 把文件系统和 Git 变成了 Agent 的 "外部记忆"。每一轮迭代产生的代码、日志、评估分数、实验记录，都被结构化地保存在一个共享的制品仓库中。下一个 Agent 会话启动时，它可以直接读取这些"前人的经验"。

这带来了几个关键好处：

知识积累：Agent 不会重复已经失败的尝试，每一轮都在前一轮的基础上前进
可追溯性：每一个实验结果都有完整的 Git 历史，可以回溯到哪一步、哪个改动导致了性能变化
多 Agent 协作：不同 Agent 会话可以"看到"彼此的工作，形成隐式的协作关系

这本质上是在给 Agent 造一个"科研档案库"。就像人类科学家依赖论文和实验记录来积累知识一样，Agent 也需要一个结构化的记忆系统。

支柱三：预算工程（Budget Engineering）

这个设计非常巧妙。EurekAgent 给每个 Agent 会话设定了时间和 API 成本的预算上限。

乍一看，这像是一个限制。但实际上，这是逼 Agent 学会高效决策。

没有预算约束的 Agent，可能会无限地尝试各种方法，直到找到最优解。这在理论上没问题，但在实践中意味着巨大的资源浪费。有预算约束的 Agent，则需要：

在开始前评估哪些方向最有希望
在实验过程中动态判断"这条路值不值得继续"
在探索广度和深度之间找到平衡

这其实和人类科学家的处境非常相似——没有人有无限的经费和时间。预算约束不是 bug，而是真实世界科研的 feature。

而且，EurekAgent 的结果表明，有预算约束的 Agent 不仅没有变差，反而在极低的成本下（不到 11 美元）就达到了 SOTA。这说明：好的约束，激发好的策略。

支柱四：人机交互工程（Human-in-the-loop Engineering）

EurekAgent 不是要取代人类，而是重新定义人类在科研中的角色。

它提供了三个关键的人机交互接口：

暂停/回滚：人类可以随时暂停 Agent 的运行，审查当前状态，如果发现问题就回滚到上一个检查点
关键节点审核：在 Agent 提出新假设时，人类可以选择性地审核提案，确保方向合理
环境问题介入：如果 Agent 发现实验环境配置有问题（比如依赖安装失败、数据格式异常），它可以主动请求人类澄清，而不是盲目地继续

这呼应了论文中提出的一个深刻洞察——科研范式的转变：人类从"执行者"变成"方向制定者"和"质量监督者"，Agent 负责大规模的方法探索。

这不是"AI 取代人类"，而是"人机分工的重新定义"。人类负责定义问题、设定标准、把关质量，AI 负责在巨大的可能性空间中高效搜索。

扩展阅读：从 Prompt 到 Environment——AI 工程的四次进化

理解了 EurekAgent 的实践，我们不妨把视野拉得更远一些。中科院自动化所的综述，为我们提供了一个更大的历史框架。

回顾 AI 应用开发的历史，我们可以清晰地看到四代范式更迭：

时代	核心范式	核心问题	代表工具
1	Prompt Engineering	怎么问才能得到好答案？	Few-shot、Chain-of-Thought
2	Workflow Engineering	怎么把多个调用串起来？	LangChain、Dify、Coze
3	Loop Engineering	怎么让 Agent 自己转起来？	Claude Code、Codex、Cursor
4	Environment Engineering	给 Agent 一个什么样的世界？	EurekAgent、Harness

这个演进不是简单的概念替换，而是抽象层级的不断提升：

Prompt Engineering 关注的是单次交互的质量
Workflow Engineering 关注的是多次交互的组织
Loop Engineering 关注的是自主循环的设计
Environment Engineering 关注的是整个交互系统的构建

层级的每次提升，都意味着人类工程师从更底层的细节中解放出来，去思考更上层、更根本的问题。

而环境工程可能是这个演化链上最关键的一步——因为它第一次把"环境"这个一直被当作背景的条件，变成了设计的一等公民。

深度扩展：Agent 和环境的"共同进化"

中科院综述中最令我兴奋的部分，不是静态的环境分类，而是关于 Agent 与环境共同进化（co-evolution） 的讨论。

Agent 怎样在环境中成长？

综述提出了四条互补的进化路径，形成了一个完整的 Agent 能力提升框架：

1. 记忆驱动（Memory-Centric）——从经验中学习

这是最直觉的方式。Agent 把过去成功的策略、失败的教训存储下来，在后续任务中复用。就像人类从经验中学习一样。

2. 编排驱动（Orchestration-Centric）——动态调整策略

Agent 不固守一套固定的工作流，而是根据当前任务特征和环境反馈，动态调整自己的行动序列和协作模式。在不同环境中，它可能采用完全不同的策略。

3. 轨迹驱动（Trajectory-Centric）——离线学习

Agent 在环境中运行产生大量交互轨迹（状态-动作-奖励序列），这些数据可以在离线阶段被用来训练更好的策略。这类似于 AlphaGo 用人类棋谱做预训练。

4. 探索驱动（Exploration-Centric）——在线强化学习

Agent 在与环境的实时交互中，通过强化学习持续优化自己的行为。这是目前最前沿的方向，也是让 Agent 实现真正自主进化的关键。

环境怎样为 Agent 而进化？

反过来，环境也不是一成不变的。综述识别了三种环境进化的方式：

1. 神经驱动（Neural-Driven）——让环境"学会"变化

环境的内部参数可以通过神经网络来调整，模拟出多样化的场景。这就像给 Agent 配了一个"会变形的训练场"，让它能适应各种可能的情况。

2. 难度驱动（Difficulty-Driven）——课程学习

环境根据 Agent 当前的能力水平，动态调整任务难度。Agent 刚入门时，环境简单友好；Agent 变强后，环境跟着变难。这就是"课程学习"（curriculum learning）——让 Agent 始终处于"最近发展区"。

3. 规模驱动（Scaling-Driven）——不断扩大边界

环境不断引入新的场景类型、新的任务结构、新的约束条件，推动 Agent 向更广泛的泛化能力发展。这就像"不断拓宽的赛道"，让 Agent 的能力边界持续外扩。

这个双向视角意味着什么？

传统的 AI 开发思维是"单向的"：先造好环境，再训练 Agent，然后部署。环境是固定的，Agent 是被动的。

但共同进化的视角告诉我们：AI 智能体的发展不是一个单向的"训练-部署"过程，而是一个 Agent 和环境相互塑造、共同进步的动态系统。 这可能是未来 AI 系统设计中最重要的元原则。

场景延展：环境工程不止于科研

你可能会想，这些概念听起来很学术，跟普通开发者有什么关系？

实际上，环境工程的思想正在渗透到 AI 应用的各个层面。

场景一：AI 编程助手

Claude Code 和 Codex 这些工具，本质上就是在做"环境工程"——它们给 Agent 提供文件系统访问、终端执行、代码搜索等工具，同时通过权限控制（比如不能直接修改生产环境）、上下文管理（比如读取项目结构）来约束 Agent 的行为。一个好的 AI 编程助手，核心不是 prompt 写得有多好，而是它操作的"工程环境"设计得有多合理。

场景二：企业级 AI 应用

Salesforce、SAP 等平台在 2026 年密集引入 Harness Engineering 的理念。在企业场景中，环境工程意味着：定义 Agent 可以访问哪些数据、不能触碰哪些系统、在什么条件下需要人类审批。这不是技术限制，而是治理框架——让 AI 在可控的边界内发挥最大效能。

场景三：AI 安全与对齐

OpenAI 和 Anthropic 一直在研究如何让 AI "对齐"人类价值观。环境工程提供了一个新的视角：与其试图在模型内部"灌输"价值观，不如设计一个让"好行为"被自然激励、让"坏行为"被自然抑制的环境。 这比 prompt 层面的"道德说教"更根本，也更可靠。

未来展望：三个值得关注的命题

命题一：环境即服务（Environment-as-a-Service, EaaS）

中科院综述提出了一个前瞻概念：如果环境可以被标准化，它就可以像云计算一样被"按需使用"。

想象一个未来：你想让 AI 做一个新的药物分子设计任务，你不需要自己搭建分子模拟环境、评估基准、安全协议——你只需要从一个"环境市场"中选择一个经过验证的、符合行业标准的药物发现环境，直接让 Agent 在其中运行。环境的质量、安全性、可复现性都由服务提供商保证。

这个愿景一旦实现，AI 科研的门槛将大幅降低，而可靠性将大幅提升。

命题二：多 Agent 环境

综述明确指出：现有的大多数环境是为单 Agent 设计的，这在多 Agent 协作场景下严重不足。

在现实世界中，科研、工程、商业都涉及大量 Agent 之间的协作、竞争、协商。如何设计一个支持多 Agent 高效协作、避免冲突、共享资源的环境？这个问题几乎未被系统性探索。

命题三：神经-符号融合环境

这是综述论文结尾重墨描绘的方向。符号系统提供精确的反馈和可验证的规则，但场景覆盖有限。神经系统提供无限的场景生成和灵活的语言交互，但反馈可能不准确。如何融合两者，让环境同时拥有可靠性和可扩展性？ 这可能是环境工程领域最核心的技术挑战。

写在最后：智能，从来不是孤立的

回顾这两篇论文，我最大的感触是：它们提醒我们一个被长期忽视的真相——智能从来不是发生在真空中的。

过去几年，AI 领域的叙事几乎完全围绕着"模型"展开：GPT-4、GPT-5、Gemini、Claude、Kimi……更大的参数、更强的推理、更长的上下文。但环境工程告诉我们：一个智能体的能力，永远是其自身与环境交互的产物。 你给再聪明的 Agent 一个糟糕的环境，它也只能做出糟糕的成果。

Gibson 在将近 50 年前就说过：环境塑造了行动的可能性，"either for good or ill"。今天，当我们试图让 AI 成为真正的科研伙伴、工程助手、创意协作者时，这句话的分量比任何时候都重。

我们不是在建造更聪明的机器，而是在设计更聪明的世界。

参考论文

Li, J., Jin, Z., Men, T., et al. (2026). Agentic Environment Engineering for Large Language Models: A Survey of Environment Modeling, Synthesis, Evaluation, and Application. arXiv:2606.12191. 中国科学院自动化研究所模式识别国家重点实验室.
Xin, A., Siow, J., Wang, J., et al. (2026). EurekAgent: Agent Environment Engineering is All You Need For Autonomous Scientific Discovery. arXiv:2606.13662. 清华大学计算机科学与技术系.

本文基于两篇 arXiv 论文的公开内容撰写，结合了论文的核心论述与笔者的延伸解读。文中所有实验数据均来自论文原文。