自主 Code Agent 的托管方式、工具、护栏和错误恢复机制有何差异？
自主 Code Agent 的核心循环看起来确实相似：读取任务与仓库、调用工具修改代码、运行检查、根据反馈继续迭代，最后交付提交或拉取请求。但产品之间真正拉开差距的，并不是循环是否叫 ReAct，也不是界面里能同时展示几个 Agent，而是这个循环在什么环境中运行、获得什么权限、由哪些机械规则约束，以及进程中断或结果错误后能否可靠恢复。对团队而言，选择 Code Agent 实际上是在选择一套执行与治理系统。
判断差异时，可以把模型能力暂时放到一边，依次检查四层：托管方式决定运维责任和隔离边界；工具与编排决定它能接入哪些现有流程；护栏决定错误能否在进入主分支或生产环境前被拦下；错误恢复决定长任务是否具备可追踪、可重试、可回滚的工程属性。只有四层一起看，才能区分“会写代码的会话”与“可持续运行的自主开发系统”。
托管方式决定控制权、成本与隔离强度
厂商托管云：启动快，但运行边界由平台定义
云端自主 Agent 通常在厂商管理的虚拟机中异步执行。用户连接代码仓库并提交任务后，可以关闭本地电脑，稍后接收差异、测试结果或拉取请求。这类方案的优势是环境创建、会话生命周期、并发调度和基础隔离已经产品化，团队不必维护常驻调度器。它尤其适合边界清楚、能够通过拉取请求交付的任务，例如依赖升级、小范围缺陷修复和测试补充。
代价是控制面由供应商掌握。网络出口、可安装软件、会话时长、并发额度、区域与数据保留策略都可能受平台限制。即使 Agent 位于隔离虚拟机中，团队仍需确认源码如何进入环境、密钥是否真的不落入沙箱、认证是否通过短期且有范围限制的代理凭证完成，以及构建产物和日志会保留多久。所谓“托管”只转移了基础设施责任，并没有转移数据治理责任。
本地或桌面编排：开发体验直接，安全取决于宿主机
本地编排器常用 Git worktree、独立分支或后台终端会话同时运行多个 Agent。优势是可以复用开发者已经配置好的编译器、缓存、私有依赖和调试工具，也容易人工查看实时输出与差异。对于个人开发者或少量并行任务，它通常比搭建服务端平台更轻。
但 worktree 只解决文件冲突，不等于安全沙箱。多个工作树仍可能共享用户凭证、网络、容器守护进程、系统目录或全局缓存。一个拥有完整 shell 权限的 Agent，影响范围可能远超当前分支。评估本地方案时，要分别询问“代码目录是否隔离”和“进程权限是否隔离”：前者防止并行修改互相覆盖，后者才限制危险命令、凭证读取和横向访问。
自托管服务与 Kubernetes：控制力强，也带来平台负担
自托管调度服务可以轮询工单系统，为每个任务创建独立工作区或容器，再启动指定的编码 Agent。Kubernetes 形态进一步提供命名空间、网络策略、资源配额和按任务创建的短期权限，适合需要多租户、审计、弹性并发和内部网络访问的大型团队。这类架构的关键价值不是“能跑更多 Agent”，而是能把每次执行变成一个可声明、可观测、可回收的工作负载。
相应地，团队必须维护镜像、队列、控制器、密钥代理、日志、存储和故障处理。若每天只有少量简单任务，平台成本可能高于收益。一个由工单标签触发的 CI 工作流，创建临时执行环境、运行 Agent、执行测试并打开拉取请求，往往已经能覆盖大部分价值。先证明任务适合自动化，再升级为常驻编排平台，比一开始建设完整 Agent 集群更稳妥。
工具差异不在数量，而在权限和反馈是否闭环
工具列表很长并不代表 Agent 更可靠。真正重要的是工具是否返回结构化结果、调用权限能否按任务收窄，以及调用结果能否进入下一轮判断。代码搜索、文件编辑、shell、测试和版本控制是基础工具；工单、代码托管、CI、部署和可观测性接口则把单次编码会话连接到软件交付流程。
接入方式大致分为硬编码集成、协议化工具和适配器架构。硬编码集成配置少，但容易被某个代码托管平台或工单系统锁定；协议化工具可以通过统一调用接口暴露外部能力，但协议只统一“怎么调用”，并不会自动解决授权、幂等和审计；适配器架构把 Agent 运行时、仓库和任务管理器拆开，替换模型或平台更容易，却要求团队维护清晰的契约与兼容测试。
需要特别警惕把“工具可用”误解为“工具可以无限使用”。读取工单与创建部署的风险等级完全不同。成熟系统会为工具标注只读或写入属性、资源范围、超时、预算和审批条件，并记录参数与结果摘要。涉及推送分支、修改工单、访问生产数据或触发部署的工具，应使用短期凭证和幂等键；重复调用必须能识别上一次是否已经成功，避免网络超时后再次执行造成双重副作用。
护栏应由多层机制组成
环境护栏限制“能碰什么”
第一层是执行隔离，包括虚拟机、容器、操作系统沙箱、网络策略和只挂载必要目录。默认拒绝网络、按域名放行、禁止访问宿主机套接字、限制 CPU 与内存，能够降低错误命令的破坏范围。凭证不应以长期环境变量直接注入沙箱，而应由代理根据当前操作签发短期、最小权限的令牌。
任务护栏限制“这次允许做什么”
仅有角色权限仍然过宽。任务级权限应进一步限定仓库、分支、目录、外部 API 和有效时间。例如，一个修改前端组件的任务没有理由获得生产数据库写权限；一个只需生成补丁的任务也不必拥有合并主分支的能力。预算同样是一种护栏：限定模型调用、运行时间、并行度和工具次数，可以阻止 Agent 在无法收敛的循环中持续消耗资源。
质量护栏限制“什么结果可以交付”
质量门不能只靠 Agent 自己声明“测试通过”。可靠做法是由独立执行器运行格式检查、静态分析、单元测试、集成测试、安全扫描和架构约束，并保存退出码与日志。高风险变更还应要求人工批准。这里可以采用三种不同自治等级：高风险任务逐项审批；成熟流程由人监控异常；规则稳定且测试充分的低风险任务才允许自动完成。自治等级应随任务风险变化，而不是为整个组织设置一个统一开关。
机械检查也有边界。测试只能证明已编码的预期，不能弥补含糊的任务说明；代码能够编译，也不表示业务行为正确。因此，好的护栏从任务进入队列之前就开始：明确验收标准、允许修改的范围、禁止事项和回滚条件。编排平台可以执行这些规则，但不能替团队创造缺失的规格和测试资产。
错误恢复的重点是保存事实，而不是盲目重试
长时间自主执行必然遇到模型超时、工具失败、测试不稳定、网络中断、进程退出和代码冲突。恢复能力首先依赖持久化状态。系统至少应记录任务标识、输入规格、仓库提交基线、工作分支、Agent 与模型版本、工具调用、权限范围、预算消耗、每次检查结果和最终产物。没有这些事实，重新启动只能从头猜测，也无法判断一次有副作用的调用是否已经完成。
任务状态应显式区分排队、执行、等待审批、验证失败、可重试失败、永久失败和已完成。重试策略也要按错误分类：临时网络错误可以指数退避；测试断言失败应把日志反馈给 Agent 修正；权限拒绝通常需要调整授权或人工处理；规格冲突和重复多次不收敛则应停止。对所有错误统一重启 Agent，会浪费预算，还可能反复产生相同的危险操作。
工作区恢复通常有两条路线。其一是保留任务分支、工作树或容器卷，从最近检查点继续；其二是根据已提交的中间结果，在干净环境中重新构建。前者速度快，但可能继承污染状态；后者可复现性更好，却要求依赖锁定、初始化脚本和构建缓存足够可靠。实际系统可以在每个质量门之后创建提交或快照，仅从已验证检查点恢复。
多 Agent 编排还需要处理部分失败。若测试 Agent 拒绝代码，系统可以把证据交给另一个执行 Agent 修订，避免原执行者在相同上下文中重复原判断；若并行任务修改相同文件，则应提前通过任务图、目录所有权或独立分支降低冲突，并在合并时重新运行完整检查。所谓容错，不是保证 Agent 永不出错，而是让错误被检测、隔离、记录，并以确定的规则进入修复、回滚或人工接管。
用场景而不是功能清单选型
个人开发者希望并行处理数个独立改动时，本地 worktree 编排通常足够，重点检查宿主机权限和差异审阅。团队希望把清晰工单自动变成拉取请求时，云端 Agent 或轻量自托管调度器更合适，重点检查仓库授权、CI 质量门和任务幂等。需要多租户、内部系统访问、合规审计和大规模并发时，容器或 Kubernetes 控制面才开始体现价值，重点转向短期身份、网络隔离、配额、来源追踪与集中观测。
采购或试点时，可以用同一批真实任务做验证：一次普通功能修改、一次测试失败后的修复、一次网络中断、一次越权工具调用、一次重复提交，以及一次需要人工接管的模糊任务。记录成功率之外，还要记录完成时间、人工介入次数、质量门拦截率、失败后恢复耗时、每任务成本和无法解释的工具调用。只展示顺利完成的演示，无法揭示系统在生产环境中的主要风险。
一个可落地的最小方案
多数团队不必从多 Agent 平台起步。可以先建立单任务、单工作区、单分支的异步流程：工单标签触发任务；执行器在临时环境中检出固定提交；Agent 只获得当前仓库和必要工具；外部执行器运行测试与扫描；通过后创建拉取请求，不自动合并；所有调用和检查结果写入任务记录；失败达到次数或预算上限后转人工处理。
随后再根据瓶颈演进。如果排队时间过长，增加隔离并发；如果工具绑定严重，引入适配器；如果权限难以控制，增加任务级授权和凭证代理；如果恢复成本高，加入检查点和幂等状态机；如果人工审阅成为瓶颈，先提高测试与规格质量，再逐步提升自治等级。编排复杂度应该由已观察到的问题驱动，而不是由 Agent 数量驱动。
因此，自主 Code Agent 的差异化最终体现在工程系统，而非相似的推理循环。托管方式回答运行在哪里以及谁负责基础设施，工具层回答如何接入真实工作流，护栏回答错误能造成多大影响，恢复机制回答失败后能否继续并留下可信证据。选择时优先比较隔离、权限、验证、状态和可观测性，模型与界面反而是更容易替换的部分。
