Agentic workflows in production: Mechanisms, trade-offs, costs and design patterns

生产环境中的智能代理工作流：机制、成本与权衡

发布于

2026年7月22日

28

分钟阅读

生产环境中的智能代理工作流：机制、权衡、成本与设计模式

作者

Shreyan Basu Ray

已复制

最初发布于 CoreWeave 博客的 Weights & Biases 博客，时间为 2026年7月22日。

大多数团队能够让一个代理完成一次任务。但让同一个代理在第100次完全相同的请求中以可预测的成本完成该任务，并在失败时提供可读的追踪记录，这是另一个工程问题。本文正是探讨从可运行的演示到可操作系统的差距。

这条路径贯穿机制、权衡、设计模式和经济学，将优化视为贯穿所有内容的主线而非脚注。我们将从智能代理工作流的起源开始，因为当前的设计共识主要是对2023年特定失败案例的修正，了解每个模式对应的是哪种失败，将使这些模式更容易应用。接下来将讨论：执行循环、上下文工程作为核心优化学科、智能代理工作流在生产环境中的实际成本（附有公开数据）、架构选择如何将这些成本改变一个数量级、如何评估轨迹而非答案，以及何时完全不应该构建代理。

凡涉及具体基准、产品或平台的主张，均会链接到原始来源。这一技术栈的发展速度如此之快，以至于一年前的文章在某些地方已产生误导。

智能代理工作流的起源

语言模型调用外部工具的想法早于ChatGPT。2022年5月，AI21 Labs 发布了 MRKL Systems，这是一种模块化神经符号架构，其中语言模型作为路由器，将任务委托给外部专家模块：计算器、货币转换器、API。该模型本身并不执行任何操作，它只生成参数，而周围的程序会进行调用并反馈结果。这种模型决策与执行分离的分工，仍然是生产环境代理的正确思维模型。

2023年的两篇论文将这一想法转化为可用模式。Toolformer 展示了模型可以通过大量自监督学习掌握何时调用工具、调用哪个工具以及如何将结果反馈整合。ReAct 将显式推理与具体操作和环境观察交替进行，形成了如今大多数生产代理仍使用的“思考-行动-观察”循环。Reflexion 增加了自我批评机制，失败的代理会将口头教训写入记忆，并基于此调整下一次尝试，实现了无需调整权重即可从失败中学习的效果。

随后出现了自主代理浪潮，有必要精确说明当时发生了什么错误，因为行业仍在针对这些问题进行设计。AutoGPT 于2023年3月发布，BabyAGI 于4月发布，两者都将强模型封装在开放式循环中并指向目标。它们当时非常流行但实际无法运行。失败的原因非常具体：代理会无限循环，因为终止条件模糊且模型总能找到更多改进；它们会丢失已完成的工作，因为记忆过于薄弱，导致在循环中不断重新规划；它们会消耗无限制的API预算，因为没有任何限制开支的机制；它们从不提出澄清问题，而是假设自己具备实际没有的能力并基于错误前提继续执行。

将该列表与当前生产共识进行对比。明确的终止条件。硬性步骤和预算限制。能够跨越回合的结构化状态。将问题升级至人类作为设计结果。类型化的工具契约，防止代理发明新能力。这些都不是审美偏好。每项内容都是一道伤疤。

自那以后的年份又分为两个阶段。到2024年，答案是结构化 - 基于图的框架、显式状态机、使控制流可检查而非自发生成的编排库。自2025年起，两个因素再次改变了局面。模型在工具使用和多步骤推理方面变得足够强大，过去需要链式提示的脚手架现在可以在更少、更强大的回合中完成；METR的测量发现，代理在50%可靠性下能自主完成的任务长度大约每七个月翻一番。同时，为代码代理构建的编排层被泛化为标准应用抽象。Weights & Biases将这一现象描述为"Harness时代"的到来，其中Harness本身被商品化，业务特定价值转移到技能、提示和工具中，共享的数据模型由会话组成，会话由回合组成，回合由步骤组成。

从工具调用模型到生产代理系统

这段历史在实际层面很重要。困难的部分从未是让模型决定下一步该做什么。困难的部分是界定、观察并支付模型决定后发生的事情的代价。

代理工作流程是什么

工作流程是实现目标的一系列步骤。代理工作流程是工作流程中的一种，其中有一个或多个代理在运行时决定其中一些步骤，而不是遵循完全预写好的路径。这就是全部区别。代理根据刚刚观察到的内容选择下一步操作，而不是执行固定脚本。

代理并不意味着无约束。生产级代理工作流程由明确的目标、政策、工具契约、状态、预算和成功标准所界定，代理在条件变化时在允许的操作中进行选择。区分两个常被混淆的概念很有帮助。AI代理是执行者：模型加上其指令、工具和决策逻辑。代理工作流程是更大的系统，将代理与工具、记忆、编排和反馈结合，形成能够达成目标并报告所做操作的系统。

以支持分类为例。工单到达后，代理阅读它，决定是否需要账单系统或账户系统，提取记录，检查问题是否匹配已知模式，然后起草解决方案或转交给人类。没有两张工单遵循完全相同的路径，但每条路径都是由相同的工具和规则组成的有限集合构建而成。

代理工作流程与RPA、传统AI工作流程、聊天机器人和AI代理的区别

这些类别在边缘处存在重叠，这种重叠会导致真正的架构错误。机器人流程自动化在固定顺序中执行已知步骤，当界面或数据发生变化时会失效。传统AI工作流程在预定义的管道中调用模型，因此模型可能进行分类或提取，但路径在提前固定。聊天机器人管理对话并从模型或检索索引中回答问题，但不会采取有后果的行动。代理工作流程增加了运行时规划和工具使用，因此路径会根据观察结果、错误、检索到的证据或中途学习到的约束而变化。

最后一行是团队最容易低估的部分，本文其余内容会反复回到这一点。RPA和固定流水线的工作单位成本可以放入电子表格中进行计算。而智能代理工作流的成本分布具有长尾效应，长尾部分往往是预算的终结。

执行循环：计划、行动、观察、反思

核心机制是有界控制循环。代理形成计划，选择行动，调用工具或模型，观察结果，更新状态，反思进展，并决定继续或停止。生产系统会显式定义这个循环，因为框架内部隐藏的自主性无法被测试、调试或预算管理。

要使循环可操作，需要明确几个要素。状态对象承载计划、观察结果和剩余预算。类型化工具模式定义每个动作的输入输出规范。重试策略、循环限制、每步超时时间、成本预算和终止条件决定了代理何时停止，以及停止的原因是成功、放弃还是升级处理。

无论使用何种框架，循环结构都保持一致

state = init_state(task, budget)
while
not state.done and state.budget_ok():
    plan = agent.plan(state)              # 决定下一步动作
    action = plan.next_action
    if
        action.needs_approval:             # 限制不可逆动作
        await
        human_approval(action, state)
    result = tools.call(action)           # 类型化调用，验证输入输出
    state.observe(result)                 # 将观察结果追加到状态
    state.spend(result.cost, result.latency)
    if
        agent.should_reflect(state):       # 有界自我检查
        state = agent.reflect(state)      # 修订计划或放弃假设
    state.check_termination()             # 成功、放弃或升级
return
state.summary()

这样编写循环结构非常重要，因为每个阶段都对应可观测的要素。每个计划都是可检查的决策，每个tools.call都是带有成本和延迟的类型化动作，每次观察都是后续决策所依赖的证据。当代理行为异常时，你希望看到的是哪个观察结果产生了哪个计划，而不是阅读堆栈跟踪。

这就是代理可观测性工具存在的意义，如果你尚未使用过这类工具，这里简要说明一下。Weave是Weights & Biases推出的工具包，用于开发、调试和监控AI应用。核心思想是通过在关心的函数中添加追踪代码，自动记录函数内部发生的所有情况。在Python中，这意味着只需调用一次weave.init("your-project")，然后为需要追踪的函数添加@weave.op装饰器，之后Weave会自动捕获每个调用的输入、输出、代码、token数量和成本，并将子调用嵌套在父调用之下，使多步骤运行呈现为树状结构而非扁平日志。对常见模型提供商和框架的调用会自动被识别，其他内容也可以通过相同装饰器进行包装。

import
weave
weave.init(
"incident-response-agent"
)
@weave.op # 每个装饰的
function
becomes
a
step
def
query_logs
(
service: str,
window
: str
) ->
dict
:
...
@
weave
.
op
def
run_agent
(
alert: dict
) ->
dict
: #
parent
call
,
children
nest
underneath
plan
=
agent
.
plan
(
alert
)
logs
=
query_logs
(
alert[
"service"
],
"15m"
)
...

Weave Trace2

图视图展示了操作之间的层次关系。这对于理解父子关系非常有帮助。

这个循环中还隐藏着一个成本结构，它影响着所有后续内容。每次迭代都会重新发送累积的上下文：系统提示、工具模式、对话历史和所有之前的工具结果。一个十步代理不会进行十次小规模调用，而是进行十次逐渐增大的调用。

💡 了解更多关于 Weave Trace 的内容 - https://docs.wandb.ai/weave/guides/tracking/trace-tree

‍

代理工作流如何处理复杂、多步骤和自适应任务

考虑一个值班代理响应生产警报的场景 - 某项服务错误率升高，原因未知。代理不会猜测解决方案，而是提取近期日志和指标，形成假设，并检查第二个信号以确认或排除。如果证据不符，代理会放弃该假设并检查下一个最可能的原因。代理通过逐步缩小不确定性来解决问题，而不是一次性让单个提示诊断所有内容。

分解方法的价值在于代理无法提前知道是部署回归、资源耗尽还是上游故障。每种情况都有不同的解决方案，错误猜测成本很高。每一步都对应一个具体的工具调用 - 查询指标和日志后端、搜索运行手册或过往事件的向量索引、检查依赖项的健康端点、创建或更新工单、通知人员。

这与固定运行手册脚本的区别在于检查失败时的处理方式。如果第二个信号与假设矛盾，代理会放弃该假设而不是强行坚持理论。如果警报缺乏上下文，例如没有标记受影响服务，代理会请求补充信息或检查备用来源，而不是假设。这种单一行为，即提问而非假设，是来自 AutoGPT 时代的直接教训。升级是一个首要结果而非失败：当假设或预算耗尽时，代理会通过总结已检查和排除的内容进行升级。

生产级代理工作流的核心组件

生产级代理工作流不仅仅是循环中的提示。它需要代理策略、模型、类型化工具接口、提示、状态管理、短期记忆、长期记忆、反馈机制、编排、与执行操作系统的集成以及评估。每个组件都有独特的故障模式，这也是保持它们分离而非融合成一个不透明调用的理由。

此处的提示工程是接口设计。系统指令、工具描述、响应模式、拒绝规则和示例限制了代理能执行的操作和报告方式。模糊的工具描述会导致错误的工具调用，就像模糊的 API 文档会产生糟糕的客户端代码一样。

对框架的有用测试标准是：它们只有在暴露状态、工具调用、重试和跟踪时才真正有帮助。如果框架将这些内容隐藏在便捷功能背后，这种便捷性反而会成为生产环境的负担。

内存设计：短期状态、长期知识与检索

只有在明确限定范围时，内存才能使智能体工作流具备适应性。短期记忆具有任务局部性：对话历史、草稿区、当前计划、工具观察结果、预算状态。长期记忆是跨运行周期持久化的知识：用户偏好、历史解决方案、嵌入向量、结构化事实、摘要信息和执行结果。

长期记忆能够实现适应性和个性化，同时也是静默失败的累积之处。未经筛选的内存会保留错误并导致敏感数据泄露到未来的运行中。某个失败任务后错误记录的解决方案，可能成为明天被自信检索的上下文。因此内存需要像其他契约一样明确的写入策略：规定可存储内容、可读取对象、保留周期、摘要规则、检索策略和删除路径。应尽早采用一项原则：默认情况下不要将失败或升级的任务写入长期记忆，因为这些轨迹最可能包含错误。

托管平台已形成统一实践。部分平台通过自动处理提取和整合的托管策略，配合团队所需的流水线控制自管理策略，同时提供情景记忆功能使智能体在会话间积累经验。无论后端如何实现，都应将内存变更视为模式迁移：在生产环境中启用写入前，需通过回放测试、消融实验和追踪审查进行评估。

上下文工程：注意力预算与使用方式

若有一个领域能区分成功交付可靠智能体的团队与持续与智能体对抗的团队，那就是上下文工程。提示工程关注如何措辞指令，而上下文工程关注在多步骤运行的每个时刻，窗口中应保留哪些标记，以及哪些内容应被清除、压缩或委派到其他位置。

其背后是实证依据。Anthropic关于有效上下文工程的指导将上下文视为有限资源，其边际效益递减，这一现象被称为"上下文腐化"：随着标记数量增加，模型从该窗口准确回忆信息的能力会下降。这种现象在各类模型中普遍存在，源于架构特性——每个标记都会关注所有其他标记，关系数量呈二次方增长。实际应用中的框架是"注意力预算"，每个标记都会消耗部分预算。

这种视角转变重构了大量设计原则。更长的上下文窗口并非解决上下文压力的方案，而是更多绳索。

有效的技术核心在于筛选：

• 工具范围控制：每个工具定义都会消耗标记并带来干扰。仅暴露任务所需、描述清晰的最小工具集。臃肿的工具列表会分散注意力并提高错误率，大多数智能体构建最终采用的工具数量远少于最初提案。

• 按需检索：不要预先加载智能体可能需要的所有内容，而是在上下文中保留轻量级标识符，仅在步骤需要时动态加载详细信息。

• 压缩处理：当窗口填满时，将较早的对话回合压缩为精简状态并替换原始历史。Anthropic的内部评估显示，单纯上下文编辑即可带来显著性能提升，结合记忆工具时效果更佳，在长对话评估中可大幅减少标记消耗，避免因上下文耗尽导致的失败。

• 结构化笔记：允许代理将关键决策记录到草稿本或文件中并能够回读，确保在上下文压缩后仍能保留重要信息。

• 子代理隔离：为专业代理提供独立的上下文窗口，仅向主代理返回浓缩的摘要。在Anthropic的多代理研究系统中，子代理使用隔离的窗口进行操作，返回的摘要通常为1000到2000个token。

对于事件响应代理而言，这一机制是固定的。原始日志输出是威胁其上下文的最主要因素。简单实现会在首次调用工具时将数千条日志信息直接导入窗口，导致后续运行推理质量低下。经过上下文优化的版本则让日志工具返回带有完整结果标识符的结构化摘要，将假设记录到草稿本中，仅在需要时才提取完整数据。

实际生产中代理工作流的真实成本

成本是大多数代理项目失败的主要原因，通常被当作次要因素处理。Gartner在2025年6月预测，到2027年底将有超过40%的代理AI项目被取消，原因包括成本上升、商业价值不明确和风险控制不足。模型能力并未出现在这个列表中。这些失败本质上是经济和管理层面的问题。

代理成本的成因

成本驱动因素是循环重传累积上下文。Anthropic的统计数据揭示了这一问题——代理交互使用的token量约为普通聊天交互的4倍，多代理系统则达到15倍。代理工作负载的输入到输出token比例经常达到100:1甚至更差，这意味着代理成本是输入token问题而非输出token问题，大多数基于聊天机器人定价的直觉都存在数量级的偏差。

让我们通过具体的支持分类代理案例来分析机制。假设系统提示词为6000个token（包含工具模式），包含8个步骤，每步增加约1500个token的工具结果和推理内容，每步输出300个token。每轮输入为6000加上之前每步的1500，总运行量约为90000个输入token和2400个输出token。按代表性的前沿定价（每百万输入3美元，每百万输出15美元），输入成本约0.27美元，输出成本约0.04美元，每任务总成本约0.31美元。

与使用相同系统提示词的单次分类调用（约0.02美元）相比，代理单次调用成本是其约14倍，全部差异都来自跨轮次重复传输的上下文。

若将稳定的系统提示词缓存到典型缓存读取率（为基准输入的十分之一），同一运行成本降至约0.18美元，减少约42%，这完全符合下文讨论的测量范围。按每月10万个任务计算，这一改进价值约13000美元。

每个成功任务的成本是唯一诚实的指标

按调用次数计算的成本会低估代理成本。如果分类代理70%的尝试成功且失败时重试一次，实际每个成功任务的有效成本将显著高于单次运行成本，且失败运行会消耗完整token预算后才失败。忽略失败运行的基准或仪表板总会让代理看起来比实际更便宜。

这就是为什么pass^k结果在经济层面和技术层面同样重要。一个单次尝试成功率60%、重复尝试一致性25%的代理，其可靠完成任务的单位成本将是标称值的数倍。

同样的现象也出现在已发布的基准测试数据中。在 Holistic Agent Leaderboard 的 SWE-bench 验证子集中，多个配置在相同任务集上实现了相同的 54.0% 准确率，但成本差异巨大，从约 259 美元到约 1790 美元不等。相同准确率下成本相差约七倍。没有成本维度的排行榜无法告诉你应该部署哪一个，而大多数排行榜至今仍未包含成本维度。

已发布的成本边界

一些参考数据点，均附带准确率和成本信息：

此处有两个值得关注的模式：

• 首先，准确率-成本曲线在顶端迅速趋于平缓。在深度研究数据中，对同一前沿模型从低投入提升到高投入，仅换来不到两个百分点的准确率提升，但成本却翻倍以上。

• 其次，编码任务中主力模型与前沿模型的成本差距约为三到四个指标点的六十倍。这种权衡是否值得，完全取决于错误答案对你造成的成本，这属于商业决策而非工程问题。

当预算紧张时还存在一个已记录的断崖效应。在 TestEvo-Bench 中，将每项任务支出上限设为 1 美元，使一个代理的测试生成成功率从 70.6% 降至 44.2%，另一个从 59.5% 降至 18.8%。预算上限是真实存在的控制变量，且并非免费。不同代理在预算上限下的性能衰减差异显著，这在生产环境中设置上限前值得测量。

非 token 的成本

token 消耗是可见部分。生产预算还包含工具和 API 调用成本，对搜索密集型或数据密集型代理而言，这些成本可能与推理相当；检索和向量数据库基础设施成本；随轨迹体积和详细程度扩展的轨迹存储与可观测性成本；评估成本，因为 LLM 作为裁判的评分本身也是推理；人工升级处理成本，这通常是代理转人工时最大的单位成本；以及随着底层系统变化维护工具合约所需的工程时间成本。

一个有用的实践是从第一天起就在轨迹中按任务记录每项操作的成本，并按结果分类标记，这样你可以计算每项成功任务的成本、每次升级的成本，以及成本分布而非平均值。尾部成本比平均值更重要。那些递归生成子代理或触发重试风暴的代理会产生比中位数高多个数量级的成本，如果没有每轮运行的上限，这些运行成本将没有边界。

架构与使用场景的匹配：设计选择如何影响成本和性能

代理架构的选择对成本和性能的影响远大于模型选择，而正确的架构是任务形态的函数。最关键的问题是：任务能否分解为独立分支，还是形成每个决策都约束后续选择的依赖链？

模型层级的编排是最有文档支持的成本优化方案

按使用场景划分的成本与性能特征

表格中的普遍规律是：智能体灵活性应仅应用于需要它的少数流量。大多数成功控制成本的生产系统都是先进行分类，将常规的多数流量导向廉价的确定性路径，而将完整的处理流程保留给真正需要变化的案例。路由策略通常比任何单次调用的优化更重要，因为它决定了有多少任务会进入昂贵的处理路径。

生产环境中有效的模式

最可靠的智能体模式以一种实用的方式显得平淡无奇。明确制定计划，通过模式调用工具，验证输出结果，并在明确标准下停止执行。常见的模式包括：规划、工具使用、反思、路由、检索、验证、重试和人工审批。

规划将目标分解为步骤，在环境足够稳定以使计划在多个步骤中保持有效时效果最佳。在快速变化的环境中，过度规划是一种真正的失败模式，因为智能体会承诺一个过时的计划并坚持它。工具使用使智能体超越文本处理变得有用，且应始终配备类型化模式、输入验证、身份验证和有限权限。反思能够发现真实错误，但无限制的反思会消耗预算并可能让智能体偏离正确答案，因此应设置限制，并优先使用外部评估器或确定性检查（如果存在）。

两个模式值得更多关注。路由是目前最经济的可靠性与成本优化方式。通过确定性检查、模式验证、单元测试或第二个廉价模型进行的验证，其价值超过额外的自我反思，因为它引入了模型自身推理之外的信息。

无协调崩溃的多智能体协作

多智能体工作流只有在协作通过接口进行而非开放式对话时才能实现扩展。通过明确角色、输入、输出、共享状态、预算和升级规则，添加智能体将增加容量。没有这些规则时，添加智能体会引入隐藏的依赖关系、非确定性循环、重复的工具调用以及难以归因的故障。

该领域在此存在一个值得理解而非站队的有用分歧。Anthropic报告称，其包含主智能体和子智能体的多智能体研究系统，在内部研究评估中相比单智能体配置提升了90.2%，同时指出其令牌使用量约为15倍，并指出令牌使用量解释了大部分性能差异。Cognition在《不要构建多智能体》中则持相反观点，认为基于部分上下文的智能体决策会在后续步骤中产生冲突，因此单一线程能产生更连贯的结果。

双方对不同任务形态的判断都是正确的。Anthropic的任务是广度优先研究，子任务确实独立且答案价值足以覆盖令牌成本。Cognition的任务是编写代码，每个决策都会约束后续步骤，平行智能体相当于未阅读第一作者推理的第二作者。

由此引申出两个警示。在将质量提升归因于协作之前，需排除是否只是消耗了更多令牌；公平比较应控制预算变量。可靠性在跳转环节会严重衰减，一条包含10个步骤且每步可靠性为95%的链条，最终可靠性仅约60%，每个额外智能体都会增加跳转次数。

将智能体视作服务。应定义角色、契约、版本化提示、权限范围及独立评估。对于共享状态，当多个智能体确实需要共同视角时，黑板或图状态设计有效，但应优先使用消息传递而非全局可变上下文。

💡

分层优化智能体工作流

优化不是单一活动，而是包含四个层级的体系，各层级具有不同的迭代速度、成本和风险，其中最具杠杆效应的工作通常位于中间两个层级。

上下文层级已在前文讨论，通常每小时投入能获得最高回报，因为智能体工作负载主要由输入令牌主导。

缓存层级是可衡量节省最大但最被低估的领域。提示缓存通过重复前缀复用已计算的键值张量，使提供方跳过已处理内容的预填充。对三个主要提供商在多轮研究基准上的系统评估发现，提示缓存使API成本降低41-80%，首令牌生成时间提升13-31%，节省幅度随提示规模增长，50,000令牌提示时接近90%。

该研究的反直觉发现直接影响了智能体架构设计。简单的全上下文缓存并非最佳策略。仅缓存稳定系统提示在成本和延迟上表现最一致，因为全上下文缓存会为动态工具调用和结果触发缓存写入，这些内容永远不会被重用，增加了开销却无对应读取。在某个模型中，全上下文缓存导致延迟回归约9%，而仅系统提示缓存使延迟提升约31%。由于系统提示驱动了大部分收益，不同策略在成本节省上差异不大；延迟表现才是策略选择的关键差异点。

实际规则非常具体。保持可缓存前缀的稳定性，因此系统提示的开头不应包含时间戳、会话标识符或用户特定字符串，因为开头处任何一个不同的标记都会使整个前缀失效。将不可避免的动态值置于系统提示的末尾。注意动态工具发现，因为请求之间可用工具集的变更会使包含工具定义的缓存前缀失效；固定的一组通用工具比动态组装的工具缓存效果好得多。同时需注意缓存仅对输入标记进行折扣，因此任何将折扣应用于输出消耗的节省模型都是错误的。

一个值得命名的实际矛盾点在于，两个推荐的优化方案彼此冲突。旧工具调用的压缩和修剪能提升上下文质量，但会破坏缓存前缀。大多数团队的解决方案是：保持系统提示稳定并大量缓存，将对话历史和工具结果视为动态内容，以上下文质量而非缓存命中率作为管理标准。

路由层在模型能力发生变化时投入资源，相关内容已在架构部分说明。

训练层是速度最慢但能力最强的模块。当代理需要在特定重复任务中保持可靠时，微调训练优于提示迭代。ART（代理强化训练器）通过开发者接口封装了群体相对策略优化，支持多轮展开，W&B训练在无服务器后端运行，使团队无需配置GPU即可进行微调，通过最大化GPU利用率打包任务，报告成本降低高达40%，训练速度提升约1.4倍。通常的阻碍因素是奖励设计；RULER通过LLM评委对多条轨迹进行相对排序来解决此问题，无需标注数据或人工设计奖励函数，并在四个基准测试中的三个上实现了与人工设计奖励相当或更优的结果。战略要点是：在狭窄的高流量任务上使用更小的微调模型，可能在成本、延迟和可靠性上同时超越更大的提示模型，这是罕见的不需权衡的优化方案。

💡 合理的操作顺序：先修复上下文，再处理缓存，然后是路由，最后考虑训练，每一步后都要进行评估。通常跳转到更大模型的团队会发现，他们为本应在上下文中解决的问题支付了更多代价。

评估和调试代理工作流

代理评估必须对轨迹进行评分，而不仅仅是最终文本。有用的测试应记录提示、计划、工具调用、观察结果、内存读取、成本、延迟和结果，这样回归问题可以被解释而非猜测。轨迹会成为测试数据。

最重要的度量转变是从单次尝试成功率到一致性。τ-bench引入了pass^k指标，表示k次独立尝试中全部成功的比例，结果令人警醒：一个代理在单次尝试中能解决60%以上零售任务，但要求在八次尝试中全部成功时，成功率降至约25%。看似60%表现的系统，实际上可能只有四分之一的诚实测量结果。如果您的代理要面对真实用户，第100次相同请求的重要性将超过第一次。

离线评估仍然重要但存在局限性：它只能检测到你已知的失败模式，而有效代理行为的空间过于广阔，无法完全预见。因此在线评估变得至关重要。当Weights & Biases围绕生产代理重建Weave时，它提出了这一论点，指出诸如延迟、令牌数量、工具调用次数和错误率等启发式方法可以捕捉已知问题，而在线信号则通过分析代理在真实流量中的实际行为，能更广泛地发现新出现的失败模式，并将这些模式提取到离线评估数据集中。

具体来说，Weave的每个部分都对应于这个循环中遇到的具体问题。

第一个问题是无法调试不可见的内容。一个失败的代理运行只会给你最终答案，而无法说明它是如何得出这个结果的。Weave追踪通过将轨迹渲染为会话、回合和步骤，解决了这个问题，使你可以逐行查看运行过程并定位出错的步骤。由于追踪基于OpenTelemetry GenAI语义规范构建，已经发出OpenTelemetry的系统无需自定义仪器即可被理解。

第二个问题是无法判断变更是否有效。某人修改了提示，输出看起来不同，但没有人能确定质量是否提升或哪些案例出现回归。W&B Weave评估通过将数据集与评分器配对并聚合结果，解决了这个问题，使两个提示或模型版本可以在准确性、延迟和成本上进行对比，而不是仅凭主观印象。

在Weave评估中 - 评估在相同数据集上比较版本，因此提示变更可以基于准确性、延迟和成本进行判断，而不是主观印象。

第三个问题是修复测试通常意味着部署。你有一个失败的生产追踪和一个假设，唯一验证的方法就是部署。Playground通过将捕获的追踪重放至不同模型或提示，解决了这个问题，使你能在到达用户之前看到变更是否确实修复了这个具体案例。

在Playground中 - Playground将真实失败追踪重放至不同模型或提示，从而针对导致故障的精确案例测试修复方案。

第四个问题是生产故障往往无声无息。一个略微无帮助、循环或不安全的代理不会抛出异常，也没有人会为一个仅仅是糟糕的答案提交工单。监控和信号会观察实时流量并揭示这些行为问题，这正是将未知失败模式转化为数据集行的关键。

第五个问题是某些输出根本不能到达用户。防护栏通过内联应用评分器，使不安全或偏离策略的输出在成为操作前即可被标记或阻止。

跟踪轨迹级指标：任务成功率、pass^k一致性、步骤数、工具调用准确性、无效动作率、升级率、每任务令牌成本、p50和p95延迟、策略违规和用户纠正率。每成功任务的成本比每次调用的成本更诚实，因为一个便宜模型在成功前失败两次并不便宜。

编排工具和平台选择

三种主要选择分别解决不同的问题。代理框架用于编码控制流程，持久化工作流引擎负责可靠性：重试、检查点、崩溃后长期运行状态的存续。托管代理平台通过捆绑运行时、内存、工具和可观测性来减少集成工作，但会牺牲部分灵活性。在选择框架时，应优先考虑失败语义，而非框架的美观性。

在框架选择方面，LangGraph提供对有状态执行图的精细控制，LlamaIndex侧重于检索密集型代理，CrewAI则是构建多代理原型的最快路径。有两个变化需要特别指出，因为旧文章存在错误。微软已将Semantic Kernel和AutoGen合并为微软代理框架，该框架于2026年4月推出Python和.NET 1.0版本，此前两个前身项目已进入维护模式。AWS已开源Strands Agents，而Google的代理开发工具包是其生态中定义代理的通用方式。互操作性通过模型上下文协议（用于工具访问）和Agent2Agent协议（用于代理间通信）贯穿始终。

在持久化方面，Temporal、Ray、Airflow、Prefect和Dagster提供重试、检查点和长期运行状态，这些是普通代理循环所缺乏的。在托管平台方面：OpenAI的代理SDK和Responses API是官方推荐路径，而旧版Assistants API已于2026年8月26日停止支持，不应作为新项目的目标。AWS分为Bedrock AgentCore（一个与模型无关的运行时，用于托管基于任何框架的代理）和Bedrock Managed Agents。Google提供Vertex AI Agent Builder和Agent Engine，与代理开发工具包协同工作；微软提供Azure AI Foundry Agent Service，Anthropic提供Claude Agent SDK和Claude Managed Agents。

💡 贯穿所有建议的核心原则：选择满足任务需求的自主性最低的架构，仅在工作流确实需要运行时决策的地方添加代理灵活性。

生产推理的基础设施特性

如前所述，代理工作流会对推理基础设施产生不同的压力。一个采用ReAct风格的代理进行十次工具调用时，可能仅生成数百个输出标记，但需要消耗数十万个输入标记。当输入与输出比例达到约100:1时，预填充（prefill）成为主导：每个请求的大部分GPU时间都用于处理输入，而非生成输出。生成过程并非瓶颈，上下文才是。

这重新排列了基础设施的优先级列表。KV缓存命中率成为首要的操作指标，而非调优细节，因为高命中率可直接消除主要成本。分页注意力机制是当前任何服务栈的基础要求，而通过vLLM的自动前缀缓存或SGLang的RadixAttention实现的前缀缓存是自托管代理最强的服务器端杠杆。除了缓存：自动扩展、请求批处理、流式传输、模型路由、GPU内存规划、队列反压、超时处理、速率限制管理以及多区域可靠性成为关键考量。

可观测性使闭环完整。Weights & Biases 现在已成为 CoreWeave 的一部分，W&B Inference 提供托管的开源模型，这些模型可以追踪到 Weave，使这一原则变得具体。每一次推理调用都应可追溯至成本、延迟、模型版本、提示版本、缓存命中状态和最终任务结果。

权衡取舍：准确性与延迟，成本与吞吐量，灵活性与确定性

智能体工作流以确定性为代价换取适应性问题解决能力，而最佳操作点取决于任务风险和变化性。

准确性与延迟是首要考虑因素：检索、规划、反思、验证以及更大模型可以提高成功率，但每个操作都会增加顺序调用。成本与吞吐量是其次要考虑的：智能体循环会增加令牌和 GPU 使用量，因此缓存、批处理、路由、小型验证模型和硬性预算可以控制负载。灵活性与确定性是第三点：自由规划可以处理可变任务，而图结构、模式、审批门和有限状态转换可以提高可重复性。自主性与控制权决定了多少内容需要经过审批门，而个性化与隐私则是内存的权衡取舍。

第五个维度值得单独列出，因为它经常被忽视：能力与一致性。pass^k 的结果表明这些是不同的属性。增加能力并不自动带来一致性，而一致性正是生产环境所必需的。

故障模式、防护措施与治理

最困难的故障是看似有效但出现在错误上下文中的操作。现在这已成为研究课题而非民间传说。MAST（多智能体系统故障分类法）通过分析七个框架中超过 1600 条注释执行轨迹构建而成，这些轨迹具有高度的注释者一致性，识别出三类共 14 种不同的故障模式：规范与系统设计问题、智能体间对齐偏差、任务验证失败。约 40% 的观察到的故障属于第一类，约三分之一属于第二类，其余属于验证问题。

分布情况才是关键所在。大多数故障并非模型不够智能，而是设计缺陷——规范模糊、分解不当、角色不明确、缺少终止条件、步骤重复、交接时上下文丢失、输出检查不足。作者明确指出，基础模型能力的提升不足以解决全部分类问题。如果你正等待下一个模型版本来修复智能体的可靠性，证据表明这可能需要漫长的等待，因为问题出在系统设计层面。

此外还需防范提示注入、工具误用、过时或中毒的内存、无限循环、工具合同变更导致的模式漂移、部分故障、幻觉工具结果以及不一致的交接等问题。

防护措施应围绕操作本身，而不仅仅是最终文本：工具白名单、认证范围、沙箱环境、策略检查、预算限制、在重试风暴中触发的熔断器、输出验证，以及对高风险或不可逆操作的人工审批。在操作到达工具前，由代码定义的策略在代理推理循环之外进行评估，这种机制比要求模型自行监管自身更为有效。

治理使这一过程可审计：记录每项操作的审计日志、版本化提示词、版本化模型配置和工具模式、工件血缘关系、保留规则、访问控制和事件回顾。边缘情况容易被忽视：在相同输入下通过或失败的非确定性评估、静默复制成本的隐藏重试风暴、任务失败后的内存写入、在验证工具不可用时部分停机期间代理执行不可逆操作、子代理递归生成子代理且无每轮运行限制，这可能导致任务成本再增加一个数量级。

何时不应使用代理工作流

当确定性规则、SQL查询、分类器、搜索索引或RPA脚本能可靠完成任务时，代理工作流就是错误的工具。代理会增加延迟、成本、非确定性和运营复杂度，因此只有在存在真正的不确定性或适应性问题时才需要使用它们。Gartner观察到许多被定位为代理模式的用例实际上并不需要代理实现，这与买方视角的论点一致。

以下信号应促使你停止使用代理：

• 严格要求延迟或成本的环境通常无法容忍多次模型调用、反思循环和重试。

• 缺乏审批、可审计性、回滚路径、策略执行和责任归属的高风险流程不应交由代理处理。当成功标准模糊、缺乏评估数据、集成过于脆弱无法信任，或团队无法监控和调试追踪时，这种模式尤其不适用。

• 第k次通过证据再添一例：如果你的任务需要近乎确定性的一致性，却没有任何计划在重复试验中进行测量，代理在生产环境中会以测试阶段从未出现的方式令你失望。

替代方案包括规则引擎、传统机器学习服务、仅检索的RAG（无自主操作）、批处理流水线、人工介入队列或确定性工作流引擎。选择其中之一并非降级，而是将工具与问题匹配。

结论

生产环境中的关键问题不是代理能否完成任务一次，而是工作流能否安全失败、在评估中持续改进，并保持在延迟和成本预算范围内。当前设计共识中的所有内容，从显式终止条件到类型化工具到轨迹评估，都源于有人曾学到替代方案的成本。

实际路径如下：

• 从狭窄且高方差的任务开始，这类任务确实让固定流水线难以应对。

• 实现最小化循环，明确计划、工具调用、观察结果和预算，为每一步附加成本追踪。

• 从真实案例构建轨迹评估，测量重复运行中的一致性，而非单次尝试的成功率。

• 按顺序优化：上下文、缓存、路由，然后是后训练。

• 根据任务形态而非野心选择架构，记住最可记录的成本优势是让昂贵模型规划而廉价模型执行。

• 在扩大规模之前，先与一个确定性基准进行对比。如果智能体无法在可衡量的指标上超越该基准，这也是一个有价值的结果，而且现在学习的成本远低于发布后学习。

Share this article: /