最近很多团队开始尝试让 AI 编程 Agent 在浏览器里跑任务、多个人同时盯一个云端开发环境。你可能会产生一个疑问现在大家在本地终端里用 Claude Code、Codex 这类工具不是已经很顺手了吗为什么还要搬到云端去这个疑问背后其实是 AI 编程工作方式的再一次迁移从“开发者自己机器上的一套本地 harness”走向“多人在线共享的云端执行环境”。公开讨论里Charlie Holtz 是愿意认同“多人云端开发环境将取代本地 harness”这个判断的人之一。我不想把这次讨论搞成“名人背书”式的预测真正值得关心的是为什么这个判断会让许多每天和 Agent 打交道的人产生共鸣。这篇文章会把三个问题拆开讲清楚。第一harness 到底是什么为什么它比提示词工程更接近 Agent 的真正骨架第二多人云端开发环境相比本地 harness到底改变了哪个环节第三如果这个判断成立一个普通项目团队应该怎么低成本验证、怎么迁移以及有哪些安全边界不能碰。1. 为什么“本地 harness 将被取代”值得较真在过去一年里AI 编程工具的角色发生了明显的转换。早期它是“补全下一个 token”的编辑器插件后来进化成能改文件、能跑测试、能修复报错的 Agent再往后它能自己执行多步任务改完前端改后端跑完单测跑集成测试甚至直接在云端临时环境里开一个预览站点。角色改变之后一个尴尬的问题出现了Agent 的工作现场在谁手里、以什么形式存在如果你是在本地终端里运行一个 coding agent那么整个执行过程中的文件系统、会话状态、历史记录、测试输出全都绑定在那台电脑上。只有你自己能看到完整的执行轨迹。同事想知道 Agent 做了什么只能等你贴一段聊天记录或者把一次次git diff单独拉出来看。这还算好的。更常见的情况是团队里两个人同时在本地挂 Agent各改各的模块最后提交 PR 时撞在一起合并起来像一场没有裁判的辩论。另一个值得注意的信号是检索关键词里开始出现大量类似“codex harness”“deepseek harness”“deepseek harness 桌面版”“deepseek harness 插件”的组合词。这种词并不一定指向某个统一产品它反映的是很多使用者在用“模型名 harness”来指代“让模型跑起来的那层工程外壳”。有一部分是官方提供的工具组件有一部分是社区教程把某个模型简单地包进现成命令行框架。如果你在搜索时看到这些词不要默认它们是同一个东西更重要的判断是harness 已经从内部术语变成了一个被广泛使用的日常词汇。之所以说这个话题值得较真是因为它不再只是“哪个 IDE 更好用”的产品偏好问题。它关系到团队把状态、权限、日志、评审机制放在哪里把哪一层作为 Agent 的执行基础设施。当 Agent 真正开始独立完成多步骤工程任务时执行环境的可共享性和可观测性会成为一个架构决策而不是一个编辑器设置项。2. harness 到底是什么不是什么要讨论“多人云端开发环境会取代本地 harness”首先得把 harness 这个被滥用得厉害的概念说清楚。它不是一个具体软件的独占名称。这里讨论的 harness可以理解为包在语言模型外面的工程套具模型本身只负责推理和生成文本而真正让它变成“能改代码、能查文件、能执行命令、能遵循审批流程”的东西是 harness 提供的工具、上下文、权限和状态管理。用一个类比来说模型像是一个新入职的工程师的脑子推理能力很强但对你的代码库一无所知。harness 是这个新员工入职后获得的整套办公系统可能是一台开发机一堆可用工具一套项目文件访问权限一份操作手册还有必须经过审批的操作流程。同一个脑子配上一套糟糕的 harness可能只会写出正确的废话配上一套设计良好的 harness才能真正交付可运行的代码。你在网上搜索到的各种“XX 模型 harness”组合本质上都是在尝试给模型搭一套合适的办公系统。如果继续拆解一个相对完整的 agent harness 通常由几部分组成。工具执行层负责把模型的想法变成实际动作比如修改文件、运行 shell 命令、搜索代码、调用数据库客户端上下文管理负责决定该让模型看到哪些文件和历史信息避免无关内容冲淡关键信号权限与审批层负责在风险操作前拦截例如是否允许执行危险命令、是否允许写入受保护路径状态管理负责保存会话、任务清单和中间产物让 Agent 能够长时间工作并在出错时恢复。上面任何一块缺失模型的智商都很难转化为项目产出。这里需要破除几个常见误解。第一个误解是“本地 harness 等于本地模型”。完全不是一回事。即使你用的是云端模型 API只要执行环境还在你的笔记本上那依然是本地 harness。第二个误解是“harness 就是提示词”。提示词只是上下文的一部分工具定义、权限策略、执行回滚机制往往比提示词更决定成败。第三个误解是把 harness 和某个 CI/CD 产品混为一谈。确实有一家叫 Harness 的持续交付平台但这个讨论里的 harness 是一个通用工程概念指的是围绕 Agent 的整套控制壳而不是特定公司。混淆这两者会在阅读大量资料时产生不必要的困惑。3. 多人云端开发环境到底改变了什么云端的开发环境并不是一个新概念。早在 AI Agent 流行之前远程开发机、网页版 IDE、容器化工作区就已经存在很多年它们做的事情是把开发环境从个人电脑挪到服务器上。多人云端开发环境的真正区别在于这样一个转变开发环境不再只是给人用的交互界面也变成了给 Agent 用的执行空间而且这个执行空间是多个 Agent 和多个人类共享的。你可以把这种环境理解成一个类似“共享实验室”的体系。仓库、依赖、构建结果、测试报告、预览服务都在云端某个可寻址的工作区里多个 Agent 可以像多个实验员一样在里面并行工作。一名 Agent 负责重构某个模块另一名 Agent 跑全量测试第三名 Agent 站在评审视角检查安全风险和改动范围而人类则在统一的看板里审批关键操作。与本地终端里一个 Agent 单打独斗相比最大的变化不是“用浏览器访问代码”而是执行状态从个人私有变成了团队可见、可暂停、可回滚、可审计的公共资产。多人云端开发环境还有一个容易被忽略的优势它把“可临时生成”这件事变得很自然。本地每次跑集成测试、拉起一个预览服务、模拟多种依赖环境都需要开发者自己的机器具备足够的算力和磁盘。云端环境可以针对不同任务临时创建容器任务结束后直接销毁环境配置写成代码放进仓库。这意味着 Agent 可以在完全隔离的临时环境里做高风险操作而不会污染团队的主仓库或某台开发机。这个方向之所以和 Agent 化趋势高度契合本质上是因为 Agent 的工作模式更接近“在机器上执行任务”而不再只是“给人类补全代码”。当一个程序需要替你完成多步骤工程任务时它必须拥有真实可运行的环境必须能安装依赖、修改配置、执行测试、启动服务并且要能在出错后重建。个人电脑显然不能每次都承担这种不确定的风险多人共享的云端开发环境则更适合作为这类任务的默认执行层。4. 本地 harness 与多人云端开发环境对照先把两种模式放在一张表里对比后面的分析会更有方向感。对比维度本地 harness多人云端开发环境执行载体开发者个人电脑云端容器、虚拟工作区或远程开发机状态归属会话状态在本地别人不可见工作区状态在云端团队可访问、可追溯文件系统以本地磁盘为准云端共享仓库与构建产物协作方式单人或通过 Git 异步交叠多人、多 Agent 共享同一环境和评审通道计算能力受个人电脑限制可按任务申请更大算力或完整服务栈审批与审计审批发生在本地终端难以留痕审批与日志集中在团队可查的地方安全边界源码留在本地但个人电脑防护参差源码集中到云端需要额外治理访问策略离线可用较好不依赖服务端基本依赖网络和云平台成本模型固定电脑成本追加算力代价高按时或按任务计费闲置要及时回收最合适的使用阶段快速原型、私有仓库单文件修改多步 Agent 任务、并行协作、需要审计的团队场景这张表不是在说本地模式一无是处。实际上在很多场景里本地 harness 仍然是最顺手的起点。比如你只想快速让 Agent 改一个函数、跑一次单元测试本地启动几乎没有额外开销又比如项目处于高度保密阶段代码暂时不能落到任何外部环境那本地执行就是唯一选择。真正变化的是“默认位置”当 Agent 承担的任务越来越接近一个完整开发者的日常工作时团队会逐渐倾向于把主执行环境搬到云端而把本地作为一种应急和调试模式。这种位置迁移带来四个深层影响。第一状态从“我机器上的文件”变成了“团队可寻址的资源”二元的 Git 合并不足以描述 Agent 的所有中间动作云端工作区保留了命令历史、日志和缓存排错时能回放当时的环境。第二审批从“终端里按一下 y”变成了“团队通道里的一次可审计决策”这让 Agent 有可能进入更正式的工程流程。第三一次运行的结果可以被复制同一份环境定义可以由任意成员重新拉起来执行这在本地很难做到。第四单 Agent 优化的思路会被多 Agent 调度的思路取代任务拆分和资源并发成为更值得设计的事项。5. “多人 云端 Agent”会形成正向循环吗如果仅仅是换一台机器运行 Agent那还不足以构成颠覆性的判断。真正让“多人云端开发环境取代本地 harness”这个判断有分量的原因是在云端环境里Agent 工程能够形成一套持续的改进循环。本地 harness 很难沉淀团队经验。每个工程师电脑里的终端配置、权限习惯、使用的工具组合各不相同Agent 在这台电脑上跑得流畅换一个人可能就变得非常不可靠。而把执行环境搬上云端并编写成配置后环境就变成了代码。这份配置可以跟随仓库走新成员加入时不需要在自己的电脑上反复调试环境Agent 在不同任务中遇到的失败案例和策略调整也可以沉淀到公共的策略文件、日志和评测数据里。打个比方这就像数据库技术从“每个开发者本地维护一份数据文件”过渡到“统一使用一个由团队管理的数据库服务”。乍看只是把文件挪了个地方实际上却催生了事务、权限、备份、监控这一整层工程能力。云端 Agent 环境同理当多人共享一套可重复的 Agent 执行平台时工具权限、审批流、日志审计、成本配额才能被当作基础设施来设计。不过也要冷静看待。正向循环的前提是团队真的把 Agent 任务当成工程来治理而不是只在云端开一个在线编辑器。如果只是把本地终端的坏习惯原样搬到网页版终端里那依然享受不到这个循环的收益。真正会形成正向循环的团队通常具备三个特征一是所有环境都通过代码描述可以重复生成二是 Agent 的每一次关键操作都有日志和评审记录三是每次失败都会被当作改进 harness 配置的素材而不是归咎于模型不够聪明。当这三个条件成立云端多人环境就远远不只是 a remote IDE 那么简单的产品。6. 一条可落地的迁移路径从本地执行到云端共享执行趋势判断可以聊得很远但工程团队需要的是验证步骤。下面我会给出一个比较务实的迁移路径先跑通最小链路再逐步扩大范围。请注意以下代码和配置是示范模板字段可以根据自己团队的规则调整不绑定任何具体商业产品。6.1 先把项目容器化多人云端开发环境的第一步是让项目环境可重复。最常见的文件是.devcontainer/devcontainer.json它描述了一个开发容器需要的镜像、工具、端口和启动命令。单独在本地执行或推送云端时由平台根据这份配置生成工作区。{ name: team-agent-workspace, image: mcr.microsoft.com/devcontainers/universal:2, features: { ghcr.io/devcontainers/features/python:1: {}, ghcr.io/devcontainers/features/node:1: {} }, customizations: { vscode: { extensions: [ ms-python.python, dbaeumer.vscode-eslint ] } }, postCreateCommand: python -m pip install -r requirements.txt npm install, forwardPorts: [3000] }这份文件的核心价值是统一。之前团队成员总会在“我这边能跑啊”这件事上争论不休使用容器化配置后Agent 和开发者面对的是同一套可复现的环境。如果使用支持 devcontainer 的云端开发平台只需要把这个 json 放进仓库云端平台会自动根据它创建工作区。如果在本地想先体验也可以用 devcontainer 命令行工具在当前文件夹里启动容器验证。6.2 第二步把 Agent 权限和命令写进策略文件本地 harness 时代要不要允许 Agent 执行某条命令很多时候依赖你在终端里随手按下的 y 或 n。到了多人云端环境这种个人判断必须变成策略文件否则不同人在不同任务里的审批标准完全不一致。下面是一份示意性的策略文件agent-policy.yaml用于描述允许命令、禁止命令、Agent 可以修改的路径、哪些操作需要人工审批。version: 1.0 workspace: /workspace/repo tool_policy: - tool: bash enabled: true allow_prefix: - git status - git diff - git add - git commit - python -m pytest - node --test deny_pattern: - rm -rf - git push --force-with-lease - tool: file_edit allowed_roots: - /workspace/repo/src denied_files: - /workspace/repo/.env - **/*.pem approval_rules: - subject: git push mode: manual - subject: dependency_add mode: manual logging: trace_to: /var/log/agent-traces在实际项目里策略文件的设计有几个原则值得遵循。第一条是最小权限不给 Agent 任何它当前任务用不到的命令或路径权限。第二条是 deny 比 allow 更可靠你要先定义允许列表再用禁止列表补上边界。第三条是不要把密钥写进配置文件里Agent 运行时的凭证应当来自独立的安全存储并由平台注入。第四策略文件本身需要走代码评审流程不能由某个工程师随手改动。6.3 第三步给 Agent 提供云端执行入口有了受控环境还需要一个执行入口。下面是一个极简的云端 Agent 任务执行器示例run_agent_task.py它会读取task.json中的命令序列在策略限制下执行并输出结构化结果。实际生产级实现会比这复杂得多这里只是为了展示“执行层 策略层”的基本结构。极简云端 Agent 任务入口示意。 前提本脚本运行在共享云端工作区/容器中只负责把任务描述中的 shell 命令限制在白名单内不适合直接作为生产安全边界。 from __future__ import annotations import json import subprocess import sys ALLOWED_PREFIXES ( git status, git diff, git add, git commit, python -m pytest, node --test, ) def run_shell(command: str) - dict: if not any(command.startswith(p) for p in ALLOWED_PREFIXES): return {ok: False, error: fcommand not allowed: {command}} proc subprocess.run( command, shellTrue, textTrue, capture_outputTrue, cwd/workspace/repo, timeout300, ) return { ok: proc.returncode 0, exit_code: proc.returncode, stdout: proc.stdout[-4000:], stderr: proc.stderr[-4000:], } def main() - None: task_file sys.argv[1] if len(sys.argv) 1 else task.json with open(task_file, r, encodingutf-8) as f: task json.load(f) for step in task.get(steps, []): result run_shell(step[command]) print(json.dumps({step: step[name], **result}, ensure_asciiFalse)) if not result[ok]: sys.exit(1) if __name__ __main__: main()对应的task.json可以这样写{ steps: [ { name: 查看仓库状态, command: git status }, { name: 运行单元测试, command: python -m pytest } ] }跑起来的方式也很简单docker run --rm -v /srv/team-agent-data:/workspace/repo \ -e GIT_SAFE_DIRECTORY1 \ agent-workspace python run_agent_task.py task.json这里的重点是命令只能在白名单内执行执行目录固定在/workspace/repo输出结果会返回给上层调度。一旦 Agent 运行在共享环境里任何人都能看到这个容器执行了什么命令、输出了什么而不是像本地终端那样只有当事人知道。6.4 第四步把日志与回滚纳入流程把 Agent 迁到云端后最容易忽略的是日志和回滚。本地环境下命令历史就在终端里一关机就消失云端环境下你应该主动让每条命令、每次审批、每次文件修改都留下可检索记录。上面的示例已经把日志路径指向/var/log/agent-traces实际生产环境建议接入团队已有的集中日志平台按任务 ID 关联所有相关记录。回滚策略同样要在迁移前想清楚。Agent 每完成一个有意义的阶段都应该对应一次 commit 或一次 checkpoint。这样即使 Agent 后续操作把环境搞坏了团队也能回到最近的稳定点而不是从头重来。云端环境的“可重建性”也是回滚的一部分某个容器被销毁后只要镜像和配置还在可以立刻拉新容器而不需要等待某位工程师修好自己的本地环境。7. 这个判断落地前需要观察哪些信号从公开讨论看Charlie Holtz 的认同之所以有代表性是因为这类判断往往来自一线工程经验。但任何人说某个趋势会“取代”另一样事物时我们都应该问一句如果要把它当作团队决策依据到底看什么信号第一Agent 在云端环境里的多步骤任务成功率是否稳定超过本地运行的同等任务。这个指标不会只来自一次演示而需要一段时间的真实数据。第二一个团队能否把知识沉淀为可复用的 harness 配置而不是每个项目都从零开始折腾。如果云端环境让人人都能用上团队沉淀的工具权限和经验迁移的动力会显著增强如果只是换了一个远程终端那动力不大。第三安全与合规边界是否被真正解决。团队必须接受源码在云端运行并为此设计访问控制、审计和外部审查机制。云厂商不同细节标准也不同没有通解。同时也有两类说法需要警惕。其一不要相信“本地 harness 马上就会消失”。代码开发永远存在保密要求高、网络条件差、需要快速实验的时刻本地模式至少会在一个较长周期里作为重要模式存在。更准确的表述是默认执行重心会转移而不是某一天彻底消失。其二不要因为某个有影响力的技术人认同某个判断就立刻改变自己团队的架构。明星开发者站在聚光灯下其观点代表真实样本但不代表所有行业的约束条件。严谨的做法是把自己的项目放到这种模式里跑一轮小型验证用数据替代情绪。8. 常见问题与排查思路把 Agent 从本地迁到多人云端环境时会碰到一些典型问题。这里整理成一张排查表方便