Agent应用开始补基础设施

Agentic 应用正在从“模型能力展示”进入“基础设施工程”阶段。 近期，云应用平台 Render 在一篇工程文章中系统梳理了 Agent 应用的基础设施模式；AWS 等厂商也在持续强调 AgentOps、统一运行时、会话隔离和全链路追踪。行业讨论的重心已经明显变化：一年前大家还在比较哪个框架更会规划任务，现在更现实的问题是，任务跑到第 17 分钟失败后，能不能从断点继续，而不是重新消耗一遍模型、浏览器和外部工具费用。

Agentic 应用是能够围绕目标自主规划步骤、调用外部工具并根据执行结果调整后续行动的软件系统。 它与普通聊天机器人的区别，不是多了一段系统提示词，而是模型输出会触发真实动作，例如查询数据库、操作浏览器、生成文件、调用企业系统，甚至修改业务状态。

这意味着，Agent 一旦进入生产环境，就不再只是一个“LLM 请求”。它更像一条由不确定决策驱动的分布式工作流：执行时间可能从数秒延伸到数十分钟，步骤数量无法提前完全确定，外部服务会超时，模型可能重复调用工具，用户也可能在中途修改目标。传统 Web 应用里容易被忽略的问题，在 Agent 系统中都会被放大。

最大的误区：把 Agent 当成长连接聊天接口

把完整 Agent 循环塞进一次 HTTP 请求，是原型阶段最常见、也是上线后最先出问题的架构。 普通问答请求通常可以在较短时间内返回，但一个研究型 Agent 可能要执行“制定计划—搜索—抓取—解析—二次检索—撰写—校验引用”等十几个步骤。只要其中一个网页响应缓慢，整个请求就可能撞上网关、负载均衡器或运行平台的超时限制。

更麻烦的是，HTTP 连接断开不等于后端任务停止。用户看到页面报错后再次点击，后台可能同时运行两份任务；两份任务会重复消耗 token、重复发送邮件，或者对同一份业务记录执行两次写入。此时问题已经不是交互体验，而是数据一致性和成本失控。

正确的第一步是把“接收请求”和“执行任务”拆开。 API 服务只负责校验参数、创建任务记录并返回任务 ID，真正的 Agent 循环交给后台 Worker；前端通过轮询、服务器发送事件或 WebSocket 获取进度。这样即使用户关闭页面，任务也可以继续执行，Worker 异常退出后也能由其他实例接管。

| 架构方式 | 适合任务 | 主要风险 | 生产建议 | |---|---|---|---| | 单次同步 HTTP | 低延迟问答、单次结构化提取 | 请求超时、断线后状态不明 | 将总耗时控制在明确的网关时限内 | | 流式 HTTP | 文本生成、可增量展示的短任务 | 连接断开、重连困难 | 流只负责展示，不作为唯一状态来源 | | 队列加后台 Worker | 多步骤检索、浏览器操作、文件处理 | 队列堆积、重复投递 | Agent 生产任务的默认选项 | | 持久化工作流引擎 | 长周期审批、跨系统事务 | 系统复杂度和运维成本更高 | 用于小时级、天级或高价值流程 |

编排器不只是“决定下一步做什么”

任务编排器是负责保存执行状态、调度步骤并处理失败恢复的控制组件。 LangGraph 的图执行器、各类工作流引擎以及自研状态机都能承担这一角色，但框架选型并不是关键，真正关键的是执行过程能否被持久化。

一个可靠的 Agent 任务至少要记录以下状态：

• 原始目标、用户约束与成功标准；
• 当前计划及已经完成的步骤；
• 每次模型调用所使用的模型、参数和上下文版本；
• 工具调用参数、返回结果、耗时与错误类型；
• 已产生的中间文件、网页快照和结构化数据；
• 剩余 token、时间、调用次数和费用预算；
• 是否正在等待用户确认，以及确认的截止时间。

持久化检查点是 Agent 从故障位置继续执行所需的状态快照。 检查点不应只保留一整段聊天历史，因为聊天记录无法准确表达“哪个动作已经成功提交”。更稳妥的做法是，把执行状态设计为显式事件，例如 plan_created、tool_started、tool_succeeded、approval_requested 和 task_completed，再根据事件重建任务状态。

这种设计看上去比保存 messages 数组麻烦，却能回答生产环境最重要的几个问题：系统最后成功执行了什么、失败发生在哪一步、某个外部动作是否已经提交、恢复时应该从哪里开始。没有这些信息，所谓“重试”通常只是把整个 Agent 再跑一遍。

幂等比重试更重要

幂等性是同一操作被重复执行时，系统仍然保持与执行一次相同结果的能力。 队列系统通常只能现实地保证“至少投递一次”，网络超时也无法证明对方没有收到请求，因此 Agent 开发者必须默认每一个工具都有可能被重复调用。

发送邮件、创建工单、退款和写入 CRM 都不是天然幂等操作。一个常见方案是为每个有副作用的步骤生成稳定的幂等标识，标识可由任务 ID、步骤 ID 和工具版本共同组成；工具执行前先查询操作记录，执行成功后保存结果。即使 Worker 在成功写入外部系统后、更新本地状态前崩溃，恢复任务也能识别该动作已经完成。

重试策略必须根据错误类型决定，而不是捕获所有异常后重新运行。 HTTP 429、临时网络错误和部分 5xx 响应可以使用指数退避，例如在 1、2、4、8 秒后重试，并加入随机抖动避免大量 Worker 同时再次请求；权限不足、参数校验失败和内容被安全策略拒绝则不应自动重试，因为重复调用不会改变结果。

建议把错误至少分为四类：

1. 瞬时错误：网络抖动、限流、服务短暂不可用，可自动重试；
2. 永久错误：参数错误、资源不存在、权限不足，应立即失败；
3. 不确定错误：请求超时但不清楚外部动作是否成功，应先查询状态；
4. 业务风险错误：金额异常、收件人数量过多、目标超出授权，应转人工审批。

预算应该成为运行时的一等公民

执行预算是 Agent 在单个任务中可使用的时间、模型调用次数、token、工具次数和费用上限。 自主循环如果没有预算，就可能在两个失败工具之间反复尝试，表面上仍在“思考”，实际上已经进入无效循环。

生产系统不应该只设置一个总超时，而应设置多层限制。以下数值不是行业统一标准，但可以作为中等复杂度办公 Agent 的初始基线，再根据真实数据调整：

| 预算维度 | 示例初始值 | 超限后的处理 | |---|---:|---| | 单次模型调用超时 | 60 秒 | 切换备用模型或重试一次 | | 单次工具调用超时 | 30 秒 | 取消调用并按错误类型处理 | | 最大模型调用次数 | 20 次 | 要求 Agent 汇总现有结果 | | 最大工具调用次数 | 40 次 | 停止新增动作并输出缺口 | | 单任务墙钟时间 | 15 分钟 | 保存检查点，转异步或人工处理 | | 连续相同工具失败 | 3 次 | 打开熔断器，禁止继续调用 | | 高风险写操作 | 1 次审批 | 未批准不得执行 |

预算耗尽也应该是一种可解释的结束状态。 与其让用户得到一个笼统的“任务失败”，不如返回“已完成 8 个子任务，因网页访问预算耗尽，仍缺少两项数据”，并保留继续执行入口。Agent 的可靠性不等于永不失败，而是失败时可恢复、可解释且不会产生失控副作用。

队列要解决背压，而不只是异步

背压是下游处理能力不足时，上游主动减缓任务进入速度的机制。 当模型服务限流、浏览器实例占满或某个企业系统响应变慢时，如果 API 仍无限接收任务，队列长度会持续增长，最终把一次局部故障扩大成全局延迟。

队列设计至少应考虑优先级、并发上限和死信处理。交互式用户任务通常优先于夜间批处理；浏览器任务与纯文本推理应使用不同队列，因为两者的 CPU、内存和生命周期差异很大；超过最大重试次数的任务应进入死信队列，等待人工检查或专门的恢复流程，而不是永远占用主队列。

并发控制应该按照稀缺资源设置，而不是简单等于 Worker 数量。 一个 Worker 可能同时处理多个等待网络响应的任务，但浏览器、数据库连接和第三方接口都有各自上限。更合理的做法是分别设置“模型并发 50、浏览器并发 10、写操作并发 5”之类的资源信号量，并根据 429 比例和 P95 延迟动态调整。

工具运行时必须与推理层隔离

工具运行时是实际执行代码、浏览网页或访问外部系统的受控环境。 模型负责提出动作，不应该天然获得宿主机文件系统、生产数据库和所有企业凭据的访问权。把工具与编排器部署在同一个拥有高权限的进程里，开发起来方便，却相当于让任何提示注入都可能升级为真实系统操作。

最低限度的隔离措施包括：

• 每个会话或任务使用独立执行环境，避免文件和内存交叉污染；
• 凭据按工具、租户和任务动态注入，不写入提示词与日志；
• 对网络出口设置允许列表，限制任意域名访问；
• 只挂载任务所需目录，并设置 CPU、内存、磁盘与运行时间上限；
• 对数据库工具优先提供窄权限接口，而不是直接开放通用 SQL；
• 将读取、草拟、提交三类动作拆开，高风险提交需要额外授权。

MCP 等工具协议解决的是接入标准化，不会自动解决权限和可信问题。 工具描述可以告诉模型“这个工具怎么调用”，却不能证明工具实现安全，也不能替代身份认证、参数校验、审计日志和最小权限控制。生产环境仍要把每个工具视为一个独立服务来治理。

可观测性不能只看 token 和延迟

Agent 可观测性是对一次任务中的规划、模型调用、工具执行、状态变化和人工介入进行关联追踪的能力。 普通 APM 能告诉团队某个请求耗时 12 秒，却未必能解释 Agent 为什么连续搜索五次、为何选择了错误工具，以及成本为何突然翻倍。

推荐把一次用户任务设为根 Trace，把每次模型调用和工具调用设为 Span，并统一携带 task ID、tenant ID、model、tool、attempt 和 workflow version 等字段。日志中不要默认保存完整提示词和工具返回值；涉及个人信息、访问凭据和企业文档时，应先脱敏，并为原始数据设置更严格的访问权限和保留周期。

生产指标必须同时覆盖系统可靠性与任务质量。 可以从以下指标开始：

| 指标类别 | 核心指标 | 能回答的问题 | |---|---|---| | 系统 | P50/P95 完成时间、队列等待时间、Worker 利用率 | 系统是否拥堵 | | 模型 | 调用次数、token、首 token 延迟、错误率 | 模型成本和稳定性如何 | | 工具 | 成功率、超时率、重试次数、熔断次数 | 哪个外部依赖最脆弱 | | 任务 | 完成率、恢复率、预算耗尽率、人工接管率 | Agent 是否真正完成目标 | | 质量 | 引用有效率、结果采纳率、事实错误率 | 输出是否有业务价值 | | 安全 | 越权拦截数、敏感操作审批率、异常出口访问 | 自主执行是否可控 |

只看“任务完成率”也会产生误导。如果 Agent 为了提高完成率而跳过关键验证，数字可能更好，业务风险却更高。可靠性指标必须和质量评测、用户采纳率以及安全事件一起看。

确定性工作流通常优于全自主 Agent

Agentic Workflow 是在预定义流程中让模型承担部分判断工作的工作流，而 Autonomous Agent 则拥有更大的自主规划和行动空间。 两者不是先进与落后的关系，而是风险和灵活性的取舍。

报销审批、合同签署、退款和生产变更等流程，步骤明确且错误成本高，更适合“确定性骨架＋模型节点”：系统固定校验、审批和提交顺序，模型只负责分类、提取或生成建议。开放式研究、资料整理和故障探索则可以给 Agent 更大的规划自由，因为它们的路径很难提前枚举，而且错误通常可在最终提交前被发现。

多 Agent 也不应该成为默认架构。 每增加一个 Agent，就会增加一次状态同步、上下文传递、权限划分和失败恢复问题。能够由单 Agent 加三个明确工具完成的任务，没有必要拆成“经理、研究员、写作者、审核员”四个角色。角色扮演带来的演示效果很强，但生产价值必须由完成率、耗时和成本证明。

一套可执行的上线顺序

Agent 基础设施应该按风险逐层增加，而不是一次搭建完整平台。 对准备把原型推向生产的团队，可以采用以下顺序：

1. 先定义成功与失败。 明确任务什么情况下算完成、允许部分完成还是必须全量成功。
2. 把长任务移出 HTTP 请求。 引入任务记录、队列和后台 Worker，前端只订阅状态。
3. 建立显式状态机。 区分等待、运行、暂停、成功、失败、取消和待审批状态。
4. 为每个副作用动作增加幂等标识。 尤其是邮件、工单、支付、发布和数据写入。
5. 设置多层预算。 同时限制时间、步骤、模型调用、工具调用和费用。
6. 引入检查点与恢复。 至少保证进程退出后不必从第一步重跑。
7. 隔离工具执行环境。 按任务注入短期权限，限制网络、文件和计算资源。
8. 补齐 Trace 与审计。 让一次任务能串起模型、工具、队列和人工审批记录。
9. 建立离线回放集。 使用真实失败案例验证新提示词、模型和工具版本。
10. 最后才考虑多 Agent。 只有单 Agent 的职责或上下文确实无法继续拆解时再增加角色。

结论：Agent 的护城河正在从模型转向系统

2026 年 7 月的 Agent 竞争，已经不再只是“谁能调用更多工具”，而是谁能让工具调用长期保持可控。 基础模型的规划和函数调用能力仍在进步，但企业不会因为一次漂亮演示就把生产权限交给 Agent。真正决定产品能否上线的，是任务能否恢复、动作能否去重、权限能否收敛、成本能否封顶，以及事故能否被完整追溯。

Render 近期总结的基础设施模式之所以值得关注，是因为它把 Agent 拉回了软件工程的基本规律：异步任务需要队列，分布式执行需要幂等，长流程需要持久化，外部依赖需要超时与熔断，高权限动作需要隔离与审批。Agent 并没有让这些规律失效，反而因为模型行为的不确定性，让它们变得更加重要。

最实用的判断标准只有一个：关闭模型的“智能光环”后，这套系统是否仍是一套可靠的分布式应用。 如果答案是否定的，那么它大概率还只是一个 Agent Demo，而不是可以交给真实用户和真实业务的产品。

参考来源

• LangGraph GitHub 仓库：提供面向长时运行、有状态 Agent 的图执行、持久化与人工介入能力，可用于理解 Agent 编排器的工程实现。
• OpenTelemetry GitHub 组织：分布式 Trace、Metrics 和 Logs 的开放标准实现，是构建 Agent 全链路可观测性的基础参考。
• Model Context Protocol GitHub 组织：MCP 协议及相关 SDK 的开源实现，可用于了解 Agent 工具接口的标准化方式。
• Temporal GitHub 仓库：持久化工作流引擎，适合参考长任务恢复、重试、定时器和状态管理机制。
• Microsoft AutoGen GitHub 仓库：多 Agent 应用框架，可用于评估多角色协作模式及其额外工程复杂度。