让 LLM 在循环中调用工具，已经不再是构建 Agent 最难的部分。
真正困难的是把这个循环放进生产环境：运行中断后怎样恢复，代码在哪里安全执行，事件怎样流向用户界面，上下文由谁维护，模型或 prompt 变化后如何回归，Agent 应该记住什么，以及它代表谁访问外部系统。
LangChain 联合创始人 Harrison Chase 把这看成 Agent 开发的下一次抽象层跃迁：开发者不再分别选择 Agent Harness 和一组零散基础设施，而是使用一套把两者打包起来的 managed agent 服务，把精力重新集中到业务逻辑。
#Agent 开发经历了四个阶段
Harrison 将这条演进路线分成几个明显阶段。
第一阶段是 2022 年末到 2023 年初的早期 AI 框架与应用。LangChain、ChatGPT、AutoGPT 等产品开始探索 LLM 能做什么，重点是把模型接入应用，而不是今天意义上的长期运行 Agent。
第二阶段出现在 2024 年到 2025 年上半年。LangGraph、Google ADK、Vercel AI SDK 等更成熟的框架，让开发者能够显式控制状态、流程和模型调用。应用变得复杂，但多数仍是编排好的 AI 工作流。
第三阶段始于模型足以稳定执行一个简单原语：在循环中思考、调用工具、读取结果，再决定下一步。 Deep Research、Claude Code 等早期 Agent 产品都建立在这个模式上。
当循环本身稳定下来，行业开始讨论 Agent Harness。Harness 不只是几行 while loop，而是围绕模型补充正确的工具、文件系统、上下文压缩、权限边界和执行环境。Claude Code、Pi、Deep Agents 等产品的差异，很大程度上就来自 Harness 如何把模型能力组织成可持续工作的系统。
第四阶段则是 managed agents：Harness 运行在托管基础设施上，开发者通过文件、标准协议和代码配置它的行为，不再亲自组装整套生产运行环境。
#两组共识让托管成为可能
托管 Agent 并不是简单地把本地进程搬到云服务器。它的出现依赖两组逐渐稳定的行业共识。
第一组是运行 Agent Harness 所需的基础设施原语逐渐清晰。
- Durable execution ：长任务可以暂停、重试和恢复，而不是进程一死就从头开始；
- Sandbox ：模型生成或调用的不可信代码在隔离环境中执行；
- Persistence ：线程状态、文件和运行记录跨重启保存；
- Streaming ：工具调用、阶段进度和中间结果可以持续返回界面；
- Tracing ：每次模型调用、工具调用和状态变化都能回放与审计。
“大脑与双手分离”也成为常见架构。负责推理和编排的 Harness 与真正执行代码的沙箱分开运行，中间通过可持久化的 session 连接。这样模型可以在沙箱启动前开始规划，执行环境接触不到不必要的凭证，任务中断后也能从事件历史恢复。
第二组共识来自开发者如何驱动 Harness。
AGENTS.md一类文件保存基础指令和项目约定；- MCP 用统一协议接入外部系统；
- Skills 以渐进式披露的方式提供领域知识和工作流程；
- 文件系统成为 Agent 配置、上下文和长期知识的共同载体。
基础设施解决“怎样可靠运行”，标准解决“怎样表达行为”。两者成熟后，托管服务才有机会在不吞掉业务差异的前提下，接管通用运行层。
#一个生产 Agent 有三层
Harrison 把生产 Agent 拆成三个部分：
- 开发者提供的业务逻辑，包括上下文、工具、指令和领域规则；
- 让模型循环工作并管理工具与状态的 Agent Harness；
- 让 Harness 在生产环境中可靠运行的基础设施。
业务逻辑始终需要团队自己提供，因为它决定 Agent 为什么存在、可以做什么、什么结果算正确。开源或现成 Harness 已经显著降低第二层的门槛，但第三层仍包含大量与业务能力无关、每个团队又不得不重复建设的工程。
Managed agent 的产品判断是：把第二层与第三层组合成一个可部署的运行单元，同时保留第一层的可配置性。开发者选择的不再是一个孤立 Harness，而是一整套能够进入生产的执行合同。
#真正昂贵的是七类生产问题
一个 Agent 在本地完成演示，只证明模型和工具在理想条件下能够协作。要长期服务真实用户，还要回答七类问题。
#Runtime：失败之后从哪里继续
长任务可能跨越数分钟、数小时甚至更久。模型调用超时、工具失败、进程重启或等待人工批准，都不应该让整个任务丢失。运行时需要 checkpoint、重试策略和可恢复线程。
#UX：怎样让用户看见过程
Agent 不只是返回最终字符串。产品需要流式展示计划、进度、工具结果和等待状态，还要把 Agent 接入用户已经工作的 Slack、GitHub 或其他渠道。
#Sandboxes：不可信代码在哪里执行
能够写代码和调用 CLI 的 Agent 必须有受控工作区。沙箱需要隔离文件、网络、依赖与生命周期，限制一次错误或提示注入的爆炸半径。
#Context management：知识由谁维护
Instructions、skills 和其他上下文需要稳定存储、版本管理与按需加载。很多领域知识由业务专家掌握，因此系统还要允许非底层工程师安全地编辑这些内容。
#Evaluation：一次升级是否破坏了行为
修改 prompt、工具、模型或 middleware，都可能让看似无关的任务退化。生产系统需要持续评测真实轨迹，而不是只在发布前跑一组静态问答。
#Memory：什么值得跨会话保留
Agent 的长期记忆需要明确作用域、写入规则、审核和删除机制。记忆不是无限追加聊天记录，而是决定哪些信息能够影响未来行为。
#Auth：它代表谁行动
系统既要判断谁可以调用 Agent，也要限制 Agent 能做什么。当它访问外部系统时，还必须知道自己代表哪位用户、使用什么身份、权限能否传递，以及敏感操作在哪里等待批准。
这些能力彼此依赖。持久执行需要状态存储，状态需要身份隔离，工具调用需要沙箱和授权，行为变化又需要 tracing 与 eval。团队很难只挑其中一项建设而不碰到其余部分。
#“Agent 即文件”正在成为重要边界
LangChain 在无代码产品 Fleet 中尝试过一种极端托管方式：用户主要通过界面构建 Agent，但 Agent 的定义仍表现为文件系统中的文件。AGENTS.md、skills 和 MCP 配置都由 Harness 加载，甚至可以直接在文件浏览器中查看。
这种表示方式有一个关键价值：托管界面与代码之间存在出口。非开发者可以在 UI 中配置，开发团队也能把同一套定义带回代码、进入版本控制和评审流程。
不过，Fleet 的用户仍不断提出更技术化的需求，例如自定义 middleware、用代码编写工具、通过 API 批量创建 Agent。这说明“完全托管”不能等于“只能使用固定模板”。面向开发者的 managed agent 必须同时提供默认基础设施和足够深的可编程接口。
不同产品正在探索这条边界。Claude Managed Agents 更偏 API-first，用托管 Harness、环境与 session 组织生产运行；Vercel Eve 更强调把 Agent 表示成文件；Managed Deep Agents 则建立在开源 Deep Agents Harness 上，允许开发者带入自定义 middleware 和代码工具，再把运行时交给 LangSmith。
共同趋势不是某个产品名称，而是同一个分工：Agent 定义尽量保持可读、可版本化和可迁移，通用运行基础设施则由平台管理。
#托管不等于放弃控制
Managed agent 试图减少的是重复基础设施工作，不是开发者对 Agent 行为的责任。
团队仍要决定模型、指令、工具、middleware、子 Agent、身份规则、记忆策略和评测标准。平台可以负责线程、checkpoint、streaming、sandbox 生命周期和部署，但不能替团队定义什么结果正确、什么权限合理、什么失败可以接受。
这也意味着选择托管服务时，不能只比较“几分钟部署一个 Agent”。至少还要检查：
- Agent 定义能否导出并进入版本控制；
- Harness、模型与运行基础设施是否可以分别替换；
- session、memory 和文件的所有权在哪里；
- 身份和凭证是否与执行沙箱真正隔离；
- tracing 是否足以重建一次错误运行；
- eval 能否阻止模型或 prompt 升级带来的回归。
原文对托管 Agent 的态度非常乐观，但它真正提出的并不是“所有 Agent 都应该上同一朵云”，而是生产基础设施已经形成足够稳定的公共层，可以被标准化、产品化和复用。
#下一轮竞争在运行合同
早期 Agent 产品比拼谁能让模型调用更多工具，随后比拼谁能设计更好的 Harness。进入生产阶段后，差异会继续上移：谁能提供可靠、可审计、可恢复的运行合同，同时让开发者保留自己的业务逻辑。
这也是 managed agents 可能成为新默认的原因。它们降低的不是一次模型调用的难度，而是从本地原型到长期生产系统之间那段最容易被低估的距离。
Agent Loop 正在变成公共原语。真正决定系统能否规模化的，是循环之外那些不显眼的部分：状态、隔离、身份、上下文、评测，以及失败后仍能继续工作的能力。