一个类比

想象你刚招了一个顶级程序员。履历完美，面试拉满，算法手撕行云流水。入职第一天，你把他领到工位，说："干活吧。"他打开电脑，发现：

  • VPN 没开通，连不上代码仓库
  • 数据库权限没申请，查不了数据
  • 测试环境没搭好，代码写完没地方跑
  • 内网 Wiki 打不开，不知道项目规范

能力再强，也是白搭。

今天的 AI Agent，就是这个处境。我们给了它最好的模型、最精心的 Prompt、最丰富的工具。然后把它丢进一个什么都没准备好的环境里，期待它能交付结果。这不是 Agent 的问题，是我们的问题。

为什么环境这么重要？

因为 Agent 不是一次性生成答案的聊天机器人。它的工作方式是一个循环：思考 → 行动 → 观察结果 → 再思考。写一段代码，跑一下测试，看哪个用例挂了，改掉，再跑——这跟人类程序员的工作方式一模一样。

但这个循环能转起来，有一个前提：行动必须能被执行，结果必须能被观察到。

如果 Agent 写了一段代码却没有地方跑，它就不知道对不对。如果它发了一个数据库查询却连不上数据库，它就拿不到反馈。没有反馈，就没有修正。没有修正，就不可能交付。

环境不是锦上添花，它是 Agent 自我纠错的基础设施。

环境，到底难在哪？

2026年第一季度，我们团队一直在做一件事：把 AI Agent 真正用到企业的日常工作里——不是聊天机器人，而是能写代码、做审查、跑数据分析、执行运维操作的"AI 员工"。这个项目叫 LinkWork，一个开源的企业级 AI 员工平台，前几天刚完成全部开源。

在这个过程中，我们投入精力最大的地方，不是模型选型，不是 Prompt 调优，也不是怎么去构建自己的Agent 运行时，而是环境。

第一关：Agent 在哪里跑代码？

最朴素的想法：给它一个容器，让它在里面折腾。

但问题马上来了：这个容器和业务环境是什么关系？

  • 如果 Agent 直接在业务容器里跑，那它一条 rm -rf 就能把你的服务删了
  • 如果 Agent 的容器完全隔离，那它又碰不到业务代码和依赖

我们的做法是双容器模式——同一个 Pod 里放两个容器：一个是 Agent 的"大脑"，负责思考和决策；一个是 Runner，是真正执行命令的"手脚"。

所以答案是两个容器各司其职：Agent 容器的环境是标准化的，Runner 容器可以按业务需求定制。两者通过原子调度绑在一起——要么同时启动，要么都不启动。

第二关：Agent 怎么连上外面的世界？

Agent 部署在服务器上（通常是 K8s 集群里），但它要干的活几乎都在"外面"：

  • 调用 LLM 的 API——在公网
  • 查 Email、发企业微信——在办公网
  • 读写 GitLab——在内网
  • 访问数据库——在业务网

四个不同的网络域。我们选择的是"默认关闭，统一代理"。Agent 的容器默认是不能上网的。当它需要调用外部工具的时候，所有请求都走一个统一的网关——我们叫它 MCP Gateway。

网关是 Agent 通往外部世界的唯一出口。它部署在能够触达各个网络域的位置，帮 Agent 代理所有的外部调用。Agent 甚至不需要持有任何凭证——API Key、Token、SSH 密钥，全部由网关代为注入。

第三关：不敢让 Agent 碰生产，但它又需要真实环境

解法是：给 Agent 一整套 Staging 环境。

不是那种缩水版的测试环境，而是一个"受控的完整环境"：

  • 数据库里有脱敏的生产数据快照
  • API 可以录制回放真实的请求响应
  • 网络拓扑跟生产一致，只是流量走的是镜像

这本质上是给 Agent 一个安全的练兵场。你可以把它理解为 Agent 的"实习期"。验证通过了，再把它"转正"到生产环境。

第四关：环境漂移——今天能跑，明天就炸

假设你的 Agent 今天跑得好好的。过了一周，同事升级了某个插件的版本，Agent 就开始报错了。这就是环境漂移。

我们在 LinkWork 里的做法是把这问题彻底消灭在"构建阶段"。我们叫它 Harness Engineering——一岗位一镜像。

意思是：每一个 AI 岗位，对应一个独立的容器镜像。这个镜像在构建的时候，就把所有东西锁死了——用哪些 Skills、用哪些工具、安全策略是什么、每个组件的版本号是多少。全部写入镜像，运行时只读。

  • 可复现：同一个镜像，无论什么时候启动，行为都是一样的
  • 可追溯：出了问题直接看镜像版本，所有配置一目了然
  • 可锁定：今天跑通的版本组合，可以永远锁住不动

第五关：多 Agent 并行时的资源争抢

在企业里，你可能同时有几十个 Agent 在跑——有做代码审查的，有做数据分析的，有做运维巡检的。

一个跑飞了的 Agent 可能把整个集群的资源吃光，让别的 Agent 全部饿死。

这就需要 Sandbox（沙箱）级别的资源隔离。

每个 Agent 都在自己的沙箱里运行，有明确的资源配额。超出配额就被限制，不会影响到别人。

LinkWork 用了 Volcano 调度器来解决这个问题——它能保证一组容器要么全部调度成功，要么全部不调度。

更深一层的思考

回过头看这五个维度，其实可以归纳成一个核心洞察：环境不是 Agent 系统的配套设施，它是 Agent 系统本身。

模型能力决定了 Agent 的"思考上限"，但环境决定了它的"行动下限"。一个模型能力 90 分但环境 30 分的 Agent，产出一定不如一个模型能力 70 分但环境 80 分的 Agent。

来看看行业里怎么做的

Agent 运行时（如 OpenClaw）——在本地运行和 Skills 生态上做到了极致，但当企业试图将其推向云端生产环境时，依然会撞上"环境隔离"和"安全管控"的墙。

个人 AI 助手（Cursor、Claude Code 等）——环境就是你的笔记本。一个人用，不存在隔离和调度问题。但也正因如此，它无法直接搬到企业场景。

Agent 框架（LangChain、CrewAI 等）——它们关注的是推理和编排，环境基本靠用户自己搞定。一旦要上生产，你会发现 80% 的工作都花在环境治理上。

写在最后

Agent 的环境问题，本质上是一个工程化问题。

它不性感，不酷，不会出现在论文里。但它是每一个想把 Agent 用到生产环境的人，都绕不过的坎。

好的雇主不只看员工的能力，还会提供完善的工作环境——明确的职责边界、安全的操作空间、充足的资源支持、清晰的协作流程。

对 AI 员工也是如此。