摘要
企业开始引入 AI Agent 时，讨论最多的通常是模型能力。它能不能理解需求，能不能拆解任务，能不能修改代码，能不能调用外部工具。这些能力决定了 Agent 是否足够聪明，但真正进入生产环境后，另一个问题会更快浮上来。
Agent 到底在哪里工作。
当 Agent 只是回答问题时，它更像一个知识助手。一旦它开始读取代码仓库、安装依赖、执行命令、访问网络、写入文件，它就变成了一个能够影响企业数字资产的执行者。企业除了需要一个会做事的 Agent，也需要一套能约束、调度、观察和回收 Agent 工作环境的基础设施。
这篇文章想讨论的正是这个问题。企业在落地 Agent 时会遇到哪些基础设施层面的风险，一个合理的执行底座应该具备什么能力，以及我司研发的 Agent Worker 如何作为这一方案的一种实现，把 Agent 的工作过程放进一个可认证、可隔离、可限制、可追踪的执行会话中。
企业真正遇到的问题，已经超出模型能力
很多 Agent 原型在演示时都很顺畅。用户输入一个需求，Agent 分析任务，生成计划，修改文件，再给出结果。看起来像是一个自然的工作流。
但企业环境跟演示环境最大的不同在于，企业有边界。
一个研发部门的代码仓库不能被其他团队随便读取，一个客户的数据不能因为某个任务配置错误而暴露给另一个任务，一次依赖安装不能污染整台服务器，一个模型生成的命令也不能在没有资源约束的情况下持续运行。哪怕 Agent 最终完成了任务，如果企业无法说明它访问过哪些文件、运行在哪个环境、结果从哪里产生，后续的审计和治理也会变得困难。
可以用一个简单例子理解。业务系统里接入了一个代码修复 Agent，用户提交需求，希望它修复移动端登录按钮错位的问题。这个任务看起来很小，但 Agent 实际要做很多动作。它要拉取仓库，创建工作分支，读取前端组件，修改样式文件，安装依赖，运行测试，再把变更提交给研发负责人确认。
如果所有这些动作都发生在同一台共享服务器上，早期可能跑得很快，后期一定会变得难管。任务之间的文件边界不清楚，依赖版本相互影响，异常进程占用资源，网络访问缺少规则，失败以后也很难复盘。单次错误只是表象，更深层的问题是企业缺少一个适合 Agent 执行任务的工作现场。
这也是 Agent 从试点走向生产时最容易被低估的部分。模型能力决定它能不能做事，执行环境决定它能不能被企业放心地使用。
企业需要的是一层 Agent 执行底座
更合理的做法，是把 Agent 的执行过程从具体应用里抽出来，做成一层基础设施。上层产品仍然负责用户体验、业务流程和结果展示，底层执行底座负责回答几个更基础的问题。
任务应该被分配到哪里运行。运行节点是否可信。每次任务是否有独立工作空间。Agent 能看到哪些文件。它能访问哪些网络资源。它最多能使用多少 CPU、内存和磁盘。任务结束后，环境如何归档、清理或复用。下一次任务是否能从可控的项目上下文继续。
这些问题放在一起，其实对应的是四类能力。企业需要一个控制面来管理任务和执行节点，需要一个隔离环境承载每次执行，需要一条受控通信链路让上层系统操作隔离环境，还需要一个项目会话模型把 Agent 的工作结果纳入现有工程流程。
这个执行底座不一定要求上层用户理解所有技术细节。对业务人员来说，它最好是透明的。用户只看到 Agent 接收任务、处理任务、返回结果。对企业 IT 和平台团队来说，它必须足够清晰，因为它承担的是安全边界、资源边界和治理边界。
换个更通俗的说法，Agent 不应该像一个拿着万能钥匙的人，在企业系统里到处找地方办公。它更应该像一个被安排进独立工作间的临时执行者。工作间里有这次任务需要的材料和工具，有明确的进出规则，有资源上限，也有完成后的清理流程。
一个合理方案的关键链路
如果把 Agent 的一次工作拆开，会看到一条相对清楚的链路。
业务系统先创建任务，并把任务和用户、项目、权限关联起来。控制面根据任务类型和资源要求选择执行节点。执行节点准备一个隔离工作环境，把项目上下文放进去。Agent 在这个环境里通过受控接口读取文件、修改文件、运行必要操作。任务过程中，控制面持续知道这个会话在哪里、由谁创建、连接是否有效。任务结束后，结果可以交给上层产品展示，工作环境也可以根据策略保留、归档或销毁。
这条链路里有几个设计决策很关键。
控制面和执行面要分开。控制面负责身份、调度和生命周期，不应该直接混在具体任务进程里。这样节点增多、任务增多、权限模型变复杂时，企业仍然有一个统一入口管理执行资源。
每次任务要有独立边界。这个边界不仅是一个目录，最好同时覆盖文件系统、网络、进程和资源配额。Agent 能够运行命令，就要假设它可能运行错误命令、长时间命令或高消耗命令。隔离环境的意义，就是把这些风险限制在当前会话里。
项目操作要有会话模型。Agent 改代码、生成文件、整理资料，都应该发生在某个项目会话中。这样后续展示差异、发起评审、合并结果、回滚失败尝试，才能接上企业已有的研发和运营流程。
通信链路要受控。让上层系统直接进入执行环境开一个无限制 shell，短期方便，长期很难治理。更稳妥的方式，是通过明确的 RPC 或工具接口暴露文件、项目和任务操作。这样权限边界、错误处理、取消任务和流式结果都能被系统化管理。
有了这条链路，企业管理者能看到的是风险被拆小了。IT 团队能看到的是节点、环境、项目、会话都有各自的位置。研发团队能看到的是 Agent 产出的结果不会绕过原有工程治理，而是进入可评审、可追踪的流程。
Agent Worker 是这套方案的一种实现
基于上面的判断，我们研发了 Agent Worker。它的定位是一套面向 AI Agent 工作任务的隔离执行基础设施，为上层产品提供稳定底座，让产品可以安全地创建、调度、运行、观察和回收 Agent 工作环境。
Agent Worker 里有几个核心角色。
Director 承担控制面职责，负责执行节点的登记、认证和连接管理。Supervisor 运行在宿主机上，承担执行节点职责，负责准备隔离环境和运行资源。MicroVM 是每次任务的独立工作空间，为 Agent 提供更清晰的文件系统、网络和资源边界。VM Agent 运行在工作空间内，负责项目、worktree 和文件操作，并通过 RPC 与外部系统通信。
这里要看的重点是职责划分。
Director 让企业有一个地方管理哪些执行节点可以接入。节点接入通过密钥签名完成身份校验，避免长期依赖共享口令。这样，执行网络里出现的每个节点都有来源、有状态，也能被启用、暂停或移除。
Supervisor 让宿主机从单纯运行脚本的机器，变成受控执行节点。它负责把宿主机能力包装成可调度资源，为每一次任务准备工作环境。上层系统不需要关心具体机器上的进程细节，只需要通过控制面请求一个符合任务要求的执行会话。
MicroVM 是 Agent Worker 对隔离边界的选择。相比把任务直接放在共享服务器目录里，MicroVM 更适合承载会执行命令、安装依赖、访问网络的 Agent 工作。它把一次任务放进独立空间里，基础运行环境和任务写入空间分开，资源使用也可以被限制在预期范围内。
VM Agent 则解决了工作空间里的项目操作问题。对代码类任务来说，它可以围绕项目创建主工作区和会话工作区，让 Agent 的修改发生在一个可追踪的上下文里。对上层产品来说，一次 Agent 工作就不再是一堆临时文件，而是一个围绕项目产生的任务会话。
关键设计带来的实际价值
Agent Worker 的价值可以从一个日常场景里看出来。
还是前面那个移动端登录按钮错位的问题。用户在企业研发平台里提交任务后，上层产品把任务交给执行底座。Director 选择可信的执行节点，Supervisor 准备隔离工作空间，VM Agent 建立项目会话。Agent 在会话工作区里读取前端文件、修改样式、运行验证。任务完成后，产品侧展示变更内容、测试结果和会话记录，由研发负责人决定是否继续评审或合并。
业务用户看到的是一个简单过程，提交问题，等待处理，查看结果。企业 IT 看到的是另一层更重要的秩序，每次任务都有独立环境，每个执行节点都经过认证，每次文件操作都处在项目会话里，资源和网络访问都有可以治理的位置。
安全隔离是最直接的收益。不同用户、不同项目、不同任务之间不共享同一个开放运行空间，误操作和越界访问的影响范围被明显压缩。
资源治理同样重要。Agent 生成的命令并不总是可预测的，尤其在安装依赖、运行测试、处理大文件时，资源消耗可能快速上升。把任务放进有边界的执行环境里，企业才能把单次任务的风险限制在可接受范围内。
可复现性也会改善。共享环境里最难排查的问题，往往是环境被谁改过。执行底座把基础环境、项目上下文和会话写入分开，问题定位会更清楚。团队可以判断失败来自项目代码、任务操作，还是执行环境配置，而不是在一台长期被污染的机器上反复猜测。
更长期的价值在于平台化。企业不会只运行一个 Agent，也不会只处理一种任务。代码修复、数据分析、文档整理、自动化测试、内部系统巡检，都可能需要类似的执行能力。把这层能力沉到 Agent Worker 这样的基础设施里，上层产品就可以专注业务体验，而不是为每个 Agent 重新设计一套运行沙箱。
把复杂性收束到正确位置
有时企业会担心，给 Agent 引入控制面、执行节点、隔离环境和项目会话，会不会让系统变重。
这个担心可以理解。很多早期试点为了快速验证效果，会直接让 Agent 在一台服务器上跑起来。对于概念验证，这样做没有问题。真正进入生产环境后，复杂性不会因为我们不设计它而消失，它只会散落在脚本、目录权限、临时账号、人工排查和运维经验里。
Agent Worker 的设计选择，是把这些复杂性收束到执行底座中。控制面处理信任和调度，执行节点处理资源和环境，MicroVM 处理隔离边界，VM Agent 处理项目会话和文件操作。每一层都只承担清楚的职责，上层产品才能保持简单。
这也是企业技术系统常见的演进方向。早期为了跑通业务，可以接受一些手工和临时方案。规模扩大以后，真正决定系统能不能长期运转的，关键会落在边界是否清楚、链路是否可控、失败是否可收敛。
结语
AI Agent 的企业落地，表面上是在引入一个更聪明的执行者，实际是在把更多自动化动作接入企业资产和业务流程。它越能做事，企业越需要认真设计它的工作现场。
一个可靠的 Agent 执行底座，应该让业务侧感觉简单，让 IT 侧看见边界，让管理侧能够审计和治理。Agent Worker 正是沿着这个方向设计的基础设施实现。它把 Agent 的每一次工作放进可管理的会话里，用控制面连接可信节点，用隔离环境承载任务执行，用项目会话承接工作结果。
当 Agent 从对话走向行动，除了让它回答得更好，还有一件事同样重要—要让它在正确的地方，以正确的方式工作。