环境反馈决定能力边界

扩展 Agent 能力边界的手段，是把内部环境改造成有反馈、可验证，而不是继续调优提示词。

模型能做到哪一步，取决于问题有没有可验证的反馈。编译和测试最先被解决，不是因为它们简单，而是因为反馈公开、验证可以规模化——写错了，编译器立刻告诉你第几行。企业内部恰好相反：反馈不公开、验证不成规模，模型再强也只能在黑箱里猜。

所以扩展 Agent 能力边界最有效的手段，是把内部环境改造成有反馈、可验证的那类环境，而不是继续调提示词。提示词提升的是单轮表现，环境决定的是上限。

环境是隐形质量杀手

云端 agent 的输出质量，首要因素是「像开发者一样拥有完整的开发环境」。云端从零开始搭环境，很难判断到底搭没搭到位——它不崩、不报错，唯一的信号是输出质量轻微下降。这种下降极易被归因于「模型不行」，于是团队去换模型、改提示词，病根一直留在原地。cursor-cloud-agents

一年前模型不太利用环境，现在越来越强，环境设置反而成了能不能发挥潜力的关键。排查到最后，结论总是同一句话：云 agent 缺少执行或确认工作所需的环境。

install 与 start 分离，从最近一次成功的构建启动

环境构建是随机且容易失败的重操作。把它放在 agent 会话的关键路径上，等于把最不可靠的环节放在最前面。

做法是把 install 和 start 分开：install——装依赖、拉镜像、预置配置——幂等且可预置，进快照；start——只有会话期才需要跑的服务——留给 agent 启动时执行。后台每小时构建一次环境快照，agent 从最近一次成功的 build 启动。Cursor 的量级是 boot 快 10 倍、TTFT 快 3 倍；更要紧的是，一个坏依赖不再搞垮整支 agent 舰队，因为它们都从上一个好的快照启动。cursor-cloud-builds

同样的思路再往前一步：把 sandbox 从会话里解耦出去，容器只在模型真正需要时通过工具调用拉起，不需要容器的会话不必等它 provision 完才开始推理。Anthropic 在托管 agent 上做完这次脑手解耦，p50 TTFT 降约 60%，p95 降超 90%。anthropic-managed-agents

确定性操作交给版本化的 CLI

编译、测试、环境启动、健康检查和迁移，应该封装成版本化的 CLI 或脚本，而不是让模型逐步控制。模型负责传结构化参数，不要拼接凭证和复杂 Shell。让模型一步步敲命令，等于把一段确定性流程变成 N 次可能跑偏的概率事件。

版本化也不只是为了回滚。工具行为变了，你要能指出是哪个版本变的、影响哪几批任务。

能力按任务、权限、风险动态裁剪

Skill、内置工具、业务工具、工作流、MCP 工具和工具包统一建模为 Capability，每一步只暴露当前可用且相关的能力。解析顺序是固定的：Agent 静态能力加 Blueprint 默认能力加当前任务所需能力，先按权限过滤，再按风险过滤，最后才生成这一轮真正可见的 ToolDefinition。

这不是洁癖：可选能力越多，选择准确率越低，Schema 常驻的 token 也越高。工具数量对选择准确率的影响要持续监控，而不是等它退化成事故才发现。

代价与自检

代价是基础设施投入——镜像检查点与恢复流水线、VM 休眠与唤醒、机密脱敏与凭证管理，本质上是在搭一套「面向 agent 的企业 IT 系统」。任务短、频率低的场景不划算。

三个问题可以自查：你的 agent 每次冷启动都要重装依赖吗？环境没搭好时它会报错，还是默默变差？它当前能看到的能力里，有多少和这个任务无关？