程序在哪里运行

这个 Agent 部署在哪，是需求评审里经常被跳过、上线前才被发现的问题。这一课我们分清几种常见的运行位置：本地、服务器、Serverless、容器和沙箱，并理解为什么对 Agent 来说，运行位置不只是部署问题，而是安全与产品问题。

运行位置直接决定了一系列产品特性。用户关掉电脑后，任务还能不能继续？Agent 能不能读用户本地的文件？一次任务能不能跑三十分钟？如果执行了一条恶意命令，会不会波及生产系统？这些问题的答案，都取决于程序在哪里运行。

一个 Agent 系统里，至少有三类东西在运行。模型推理，通常在模型厂商云端，或企业私有部署。Harness，也就是 Agent 程序本身，可能在你的电脑、服务器、Serverless 或容器里。工具执行，可能是调用业务系统 API、本地终端、沙箱或浏览器。Harness 通过 API 请求模型，再去调用工具、拿回结果。

看一个对比。本地的 Coding Agent 命令行工具，模型在厂商云端，Harness 在你的电脑上，工具在你本地的终端和文件系统里执行。云端的 Coding Agent 后台任务，模型同样在云端，但 Harness 在厂商服务器上，工具在云端沙箱里的代码副本中执行。所以听到 Agent 在本地运行，要追问清楚：是 Harness 在本地、工具在本地，还是模型也在本地？

常见的运行位置有五种。本地就像在自己家干活，能访问本地文件和登录态，但关机即停，风险直接落在用户电脑上。服务器像租一间办公室，可以长期运行，但需要运维。Serverless 像按次叫的外卖骑手，免运维、按用量计费，但单次执行时长有限制，还有冷启动。容器像标准集装箱，环境一致、便于扩容。沙箱像带玻璃墙的实验室，强隔离，可以随时销毁重建。

有三个地方需要特别注意。第一，Serverless 对单次执行时间有上限，具体数值因平台而异，长时间运行的 Agent 任务通常要拆成多段，或结合队列和工作流引擎。第二，容器不等于沙箱，容器主要解决环境一致的问题，要运行模型生成的不可信代码，需要专门加固的沙箱。第三，沙箱的核心是限制：能读写哪些目录、能访问哪些网络、能用多少资源、能跑多久。

普通软件的代码是工程师写好、测试过的。而 Agent 执行的命令和代码，是模型在运行时生成的，而且可能受到注入攻击的影响。这就让运行位置从部署问题，变成了安全与产品问题。

举个例子。某个网页、Issue 或依赖包里藏着一条指令，让 Agent 读取用户的密钥目录并上传到某个地址。如果在本地直接执行，Agent 能读取用户全部文件，又能访问公网，结果就是密钥泄露。如果在沙箱中执行，它只能访问项目目录，网络只允许白名单域名，攻击会失败，而且行为被记录下来。

运行位置也决定了用户体验。要读用户本地文件、使用本地开发环境，就放在本地。要关掉电脑后任务继续，就放在服务器或云端沙箱。要同时跑二十个任务，就用可以并发扩容的云端容器或沙箱。流量忽高忽低的轻量 API 型 Agent，适合 Serverless。运行模型生成的代码，放进沙箱。数据不能离开企业内网，就用私有服务器，必要时模型也私有部署。

用两个场景做一次选型。企业内部的销售分析 Agent，Harness 放在企业服务器的容器里，便于统一管理凭据和日志；通过内网 API 访问只读视图；模型生成的分析代码在不能访问公网的沙箱里跑，因为数据敏感、代码不可信。面向客户的 SEO 诊断 SaaS，Harness 在云端，任务入队由 Worker 执行，抓取不可信网页要在隔离环境里进行。

最后，把本模块七课的内容放回同一张图。请求、Webhook 事件或定时任务触发，慢任务先入队。Harness 组装上下文和带 Schema 的工具定义，请求模型；模型只输出工具调用的 JSON；Harness 校验参数、注入凭据、发起 HTTP 请求，经过权限与护栏，作用于业务 API、数据库、终端或沙箱。底下是四条支撑：运行位置、身份与权限、数据与格式、异步与触发。

再看三个误区。第一，部署是研发的事，产品不用管，其实能否后台运行、能否访问本地文件、并发能力和安全边界，都是产品特性。第二，放在容器里就安全了，容器的默认隔离不足以对抗恶意代码。第三，本地运行就不会有数据外泄，本地 Harness 仍会把上下文发给云端模型，而且在本地执行恶意命令，破坏力可能更大。

总结一下。评审 Agent 方案时，先分清模型、Harness 和工具各自在哪里运行。运行位置决定了它能访问什么、能跑多久、出事后影响多大。凡是模型生成的代码和命令，都应该放进受限的沙箱里执行。理论准备到这里就完成了，下一课是实操：亲手调通第一个 API，完成一次手动版的 Tool Calling。