将AI智能体作为分布式系统进行延迟测量

# 智能体即分布式系统。

模型位于请求路径内部，该路径包含队列、同步屏障、重试机制、缓存以及外部依赖。我发现这条路径中的延迟远超任何单次推理环节所带来的延迟。

完整的一次运行才是有意义的度量单位。提供商的控制台可以告诉我首个令牌的生成时间、每秒令牌数、输入大小、输出大小以及模型处理时间。而用户等待的是：准入、鉴权、状态加载、规划、推理、检索、数据库查询、代码执行、评估、持久化和交付的全部过程。他们体验到的是这一切的组合结果。

这正是我将智能体视为一个小型分布式系统的原因。我绘制依赖图，对其边界进行插桩，设定截止时间，控制扇出，并保留足够的执行状态以说明某次请求是如何完成的。当推理处于关键路径上时，更快的模型确实有帮助。但当请求排在另一个运行任务后面，或被某个搜索API阻塞时，模型速度的提升效果就十分有限了。

我所见过的最有效的延迟优化工作，遵循着一套相当朴素的流程：测量已部署的请求；找到屏障点；在预算范围内并发执行独立工作；将确定性操作移出模型循环；减少模型调用之间传递的状态；然后用与慢速版本相同的质量检查对结果进行负载测试。

这套流程同样能捕获大多数故障：隐性串行化、无界扇出、成倍增加负载的重试、全局可变状态、过期缓存、超大上下文，以及一个拖慢整体本已接近完成的答案的缓慢分支。

## 完整运行是度量单位

我在公共请求边界处启动一个计时器，当结果持久化并可供调用方使用时停止计时。每一个内部操作都成为同一次运行的子跨度。我记录其父级、操作类型、依赖关系、队列延迟、执行时间、重试次数、缓存状态、输入与输出大小，以及终止状态。

父子关系是必要的，因为一份扁平的时序列表无法呈现哪些操作是重叠执行的。将所有跨度相加，可能得出一个比请求本身还要长的总时长。追踪记录需要能够还原实际的调度过程。

我将三项指标分开记录：

- 首个有效事件的时间——界面看起来处于空闲状态持续了多久？

- 最终结果的时间——所请求的工作实际花了多长时间？

- 可持续吞吐量——系统在维持其目标的同时，能完成多少工作？

流式传输影响第一项指标。工作节点容量影响第三项指标。单次运行内的并发可以缩短获得最终结果的时间，但如果并发压垮了共享的提供商，则会降低系统吞吐量。任何性能声明都应说明上述哪项指标发生了变化，以及其他指标相应发生了什么。

一个简单的智能体循环通常被画成这样：

> model -> tool -> model -> tool -> model -> result

我将其重新绘制为依赖图。有些工具调用需要用到更早调用所产生的值，另一些则因为代码编写顺序靠后而排在后面。只有前一种才是真正的数据依赖。

对于每条边，我记录下一个操作等待的原因：

- 数据依赖意味着某个输入尚不存在。

- 策略依赖意味着系统选择了等待。

- 资源依赖意味着工作已就绪但容量不可用。

- 展示依赖意味着有效状态已存在但界面尚未将其呈现出来。

- 偶然依赖来自实现时的代码顺序。

策略性等待、资源性等待、呈现性等待和意外性等待，为我提供了具体的排查切入点。数据依赖在更优的执行计划下可能消失，而引入异步并不会改变后续操作所需的信息。

在一组相互独立的操作中，最慢的必要分支决定了墙钟时间。依赖阶段则逐级累加。我将一次运行建模为一系列并行波次：

> 运行时间 ≈ 排队时间 + 每个波次中关键操作的总和 + 收尾时间

即便系统执行了更多的聚合工作，关键路径仍可以缩短。当额外工作可以安全地与其他操作重叠，且共享基础设施有足够余量时，这种权衡才有意义。

LLMCompiler 采用了类似的表示方法：规划器生成依赖图，调度器分发就绪任务，执行器并发运行独立函数。其基准测试结果适用于特定工作负载，而图抽象本身的适用范围则宽泛得多。Kim et al., An LLM Compiler for Parallel Function Calling (https://arxiv.org/abs/2312.04511)

## 模型轮次是同步屏障

传统的工具调用循环会反复跨越网络边界传递控制权：

> 模型做出决策
应用解析结果
工具执行操作
应用序列化数据
模型读取数据
模型再次做出决策

每一轮都可能涉及提供商排队、网络传输、推理计算、结果解析，以及又一次出错的机会。我审查智能体计划时，会逐一检查每个边界处是否真的需要将控制权交回模型。

排序、去重、算术运算、模式验证以及重复性转换，通常应当放在代码中完成。调度器可以分发已知的工具依赖关系。这些步骤由应用直接处理；只有当新证据可能改变计划时，才将模型保留在循环中。

程序化工具调用将这一思路推进了一步：模型输出一段有界程序，沙箱负责执行其控制流和工具调用，精简后的结果再返回给模型。中间记录保留在对话之外，从而省去了推理轮次和重复的上下文处理。AWS, Implementing programmatic tool calling on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/implementing-programmatic-tool-calling-on-amazon-bedrock/)

这通常形成一种混合架构：确定性阶段作为工作流运行，而模型则在需要判断的节点上选择执行路径。Anthropic 在其文档中也描述了同样的划分——一类是采用预定义路径的工作流，另一类是自主决定工具调用的智能体。Anthropic, Building effective agents (https://www.anthropic.com/engineering/building-effective-agents)

当合并结果的方式已明确定义时，独立工作应当并发执行。对不相关来源的并行搜索通常符合这一条件，对独立候选方案在统一评分标准下的评估亦然。而先获取一份文档、再依据其内容构造下一条查询，则不符合。

我将这些依赖关系表示在提示之外，使调度器能够在输入就绪后立即释放任务，其输出经过确定性归约器处理。这形成了以下几种调度模式：

- **扇出与汇聚**：分发独立分支并合并结果。

- **流水线重叠**：在剩余分区继续处理的同时，对已完成的分区启动下游工作。

- **对冲读取**：当某个安全依赖出现长尾延迟时，在延迟一段时间后发出重复请求。

- **投机读取**：在权威路径尚在决策时，提前启动很可能无副作用的操作。

- **增量归约**：在整个波次完成之前，对部分结果进行过滤或去重。

每一种方式都有其代价。对冲会消耗额外容量，投机在预测错误时会浪费工作，而增量归约器可能使结果依赖于到达顺序。只有当追踪显示有足够的等待时间来证明额外协调的必要性时，我才会使用它们。

Anthropic 的研究系统在两个层次上并行运行：协调者委派不同的研究方向，每个工作节点可以同时发出独立的工具调用。同一资料指出，并行研究会消耗大量更多资源，在工作节点需要共享上下文或严格有序的工作时并不适用。Anthropic，《我们如何构建多智能体研究系统》（https://www.anthropic.com/engineering/multi-agent-research-system）

在未梳理依赖关系的情况下增加智能体，往往只会增加消息数和推理调用次数。调度器才是产生加速效果的关键。

## 并发消耗共享容量

一个外部请求可能创建多个工作节点。一个工作节点可能发出多次模型调用，而一次模型响应又可能请求多个工具。适度的产品级并发设置，可能在下游引发大规模突发流量。

我在每个边界处设置限制：

> 每用户活跃运行数
每次运行的工作节点数
每个工作节点的工具调用数
每个工具的并发数
每个提供方的请求数与令牌数
全局执行槽位数

用户限制保障公平性。运行限制约束有缺陷的计划。工具与提供方限制保护依赖项免受突发冲击。全局限制使进程保持在其内存、连接和工作线程的预算范围内。

每个限制背后的队列都需要有自己的最大容量、排序策略、截止时间和准入规则。如果一个信号量在保护提供方的同时，让请求在队列中等待超过其有效截止时间，那么故障只是被转移到了队列中。一旦服务容量耗尽，我倾向于采用明确的拒绝或延迟策略。

智能体还会等待最慢的必要依赖项。更大的扇出会提高某个分支遭遇慢响应的概率，即便每个依赖项的平均表现都很健康。分布式服务多年来一直在应对这一尾延迟问题；智能体继承了它，并在其之上叠加了不确定性工作。

每个操作都会收到一个从运行继承的截止时间，以及一个适配剩余预算的本地超时。重试策略取决于幂等性和错误类型。可选工作需要有回退方案，调度器会取消那些已无法影响最终结果的工作。

重试值得格外谨慎。嵌套客户端可能各自独立地进行重试，直到一次失败在每一层演变为大量尝试。即时重试往往在依赖项仍处于不健康状态时就已到达。我使用有界次数、抖动退避，以及由整个运行共享的重试预算。确定性的客户端错误不应像瞬时服务器错误一样被重试。

对于可选分支，部分完成可能是可接受的。超时的必需证据请求在结果中应保持缺失状态。将其改写为似是而非的模型答案，只会通过改变任务本身来提升表面上的完成度。

生产追踪指南将慢工具、过度生成、内存增长和串行执行识别为各自独立的延迟来源。我希望追踪能保留这种区分。AWS，《使用 AgentCore Observability 优化生产智能体》（https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability/）

## 数据平面包含工具与上下文

模型推理是可见的、可计量的，也很容易被归咎。智能体还需要等待搜索、浏览器、数据库、存储、代码沙箱以及第三方 API。从调用方的视角来看，所有这些时间都属于智能体的开销。

Bian 等人将模型 API 延迟与 Web 环境延迟分开，并发现了两者各自占主导地位的工作负载。他们设计的 SpecCache 方案将预测的环境工作与权威推理路径并行执行。Bian 等人，《什么限制了智能体系统的效率？》（https://arxiv.org/abs/2510.16276）

我将每个工具视为一项服务进行性能分析。我需要了解其延迟分布、排队行为、并发响应、连接复用、重试语义、缓存安全性以及区域部署情况。我还会检查同时发出的相同读请求能否共享一个进行中的请求，以及较慢的依赖项是否存在部分替代方案。

编排框架无法弥补未建索引的查询，也无法弥补每次调用都新建连接的 HTTP 客户端所带来的问题。

缓存在多个层面都有帮助。单次运行内的记忆化（intra-run memoization）可防止同一执行轨迹重复发出相同的读请求。进行中的请求合并（in-flight coalescing）允许并发的相同读请求共享同一个 Future。跨运行缓存（cross-run caching）则在明确的标识和新鲜度策略下复用已完成的结果。我从能消除重复工作的最小范围入手。

工具结果的缓存键需要包含所有可能影响正确答案的输入：

> 工具标识
> 规范化参数
> 数据源与 Schema 版本
> 授权范围
> 用户或租户边界
> 新鲜度分类

若遗漏授权范围，可能会将某个用户的结果提供给另一个用户。若遗漏数据源版本，可能导致有效的字节数据描述的却是已过时的 Schema。缓存必须保留计算本身的标识，而不仅仅是其输出结果。

提示缓存有不同的约定。稳定的指令、工具定义、评分标准和共享文档应存放在提供商可复用的位置。动态请求数据不应在没有充分理由的情况下使该前缀失效。我会记录缓存命中的 token 数量，因为一个没有观察到命中的缓存配置几乎没有任何参考价值。OpenAI，模型指引；Google Cloud，上下文缓存（https://developers.openai.com/api/docs/guides/latest-model）（https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-context-caching）

自托管推理允许复用已编码的模型状态。Prompt Choreography 探索了在语言模型工作流的多次调用之间共享缓存的方法。其服务与训练设计与普通 API 客户端有所不同，但该研究识别了在许多多调用系统中普遍存在的重复计算问题。Bai 与 Eisner，《通过 Prompt Choreography 加速语言模型工作流》（https://aclanthology.org/2026.tacl-1.13/）

长上下文会带来另一种数据面成本。每一个保留在历史记录中的原始工具响应都可能被后续轮次处理。提示词不断增长，相关状态变得难以定位，缓存复用也变得更加脆弱。

我将工具响应视为一个接口。它返回下一步决策所需的最小结构化证据，并保留一个稳定的来源标识符以供深入检索。大型记录会先经过过滤或聚合。持久状态存放于有类型的存储中，而非仅以对话文本的形式存在。旧的交互历史在明确的信息损失策略下进行摘要压缩。当工具注册表较大时，我只暴露当前阶段所需的相关子集。

生成的 token 需要单独计费，因为模型是按顺序逐个产生它们的。路由节点或提取节点应具有严格的输出约定。OpenAI 的延迟指导将更短的输出、更少的请求、并行执行、流式传输以及确定性替代方案视为不同的优化技术。OpenAI，延迟优化（https://developers.openai.com/api/docs/guides/latency-optimization）

我努力保留支持下一次决策所需的最小状态。单纯以提示词长度作为优化目标是不恰当的。

## 并发场景下的状态与质量

原型可以将当前运行、进度、取消标志或最新结果存放在进程全局变量中。序列化掩盖了这一问题。在并发流量下，一个请求会覆盖另一个，取消操作会作用于错误的运行，或者延迟回调会将数据写入已完成的响应中。

每次运行都需要稳定的标识符和隔离的状态。只有在该运行仍持有相关租约或版本的情况下，更新才能成功。服务在宣告完成之前先持久化结果，且延迟到达的工具响应不能重新打开已处于终态的运行。

幂等性用于处理提交状态不明确的情况。客户端可能在不知道服务器是否已接受请求的情况下超时。通过幂等键，重试请求将返回已有的运行结果。有副作用的工具需要各自的幂等键，因为即使外层请求已被去重，内部操作仍可能被重放。

持久化执行可防止在重新连接或 worker 重启时重复已完成的工作。它不会缩短一次成功尝试的运行时间，但能大幅减少用户从失败中恢复所花费的时间。

质量与延迟需要相同的运行标识机制。几乎所有提速技术都可以通过削弱任务本身来美化仪表盘数据：减少工具调用、提前停止、使用过期状态、丢弃延迟结果、返回更少的证据，或切换到更弱的模型。

我在优化之前先明确质量约定。具体检查项取决于任务内容：

- 执行——运行到达了有效的终态
- 结构——必填字段能够正确解析并满足 schema 约束
- 工具行为——所调用的工具及其参数是正确的
- 证据——论断保留了来自许可来源的支撑
- 结果——用户可见的任务已完成
- 安全性——有副作用的操作遵守了策略与授权要求

比较时使用相同的输入分布和冻结的协议。对于概率性系统，我倾向于预先声明非劣效阈值，而不是主张完全等价。当使用模型对结果进行评判时，应通过人工审核的切片来验证评判模型是否与被优化的智能体存在相同的盲点。

推理力度和模型选择属于该约定的一部分。较小的路由模型在通过路由评估后，可能是一个合理的取舍。但仅因为速度更快就将其应用于所有场景，实际上是在尚未衡量效果之前就改变了推理假设。

## 界面可以展示真实的工作进展

长时间运行的请求应在最终输出形成之前就暴露有用的状态信息。在工具调用和规划阶段，我会流式传输执行事件：

> 请求已接受
计划已创建
检索分支进行中
证据审核中
最终综合已启动
结果已持久化

这些事件对应于状态转换。我不使用人为编造的完成百分比，因为智能体可能会修订其计划并产生更多工作。

接口通过运行标识符重新连接，并区分排队、运行中、等待、已完成、失败、已取消以及完成但缺少证据等状态。取消操作会在依赖项支持的情况下传播至待处理的工具和模型请求。

流式传输减少了无声等待。持久化任务状态使请求能够在断开连接后继续存活。两者均不改变最终完成时间，因此我将它们与延迟改进分开报告。Vercel，The Agent Stack，Vercel，如何构建可扩展的 AI 应用 (https://vercel.com/blog/agent-stack) (https://vercel.com/blog/how-to-build-scalable-ai-applications)

语音智能体的交互预算更为紧张，其可观测性模型对响应较慢的智能体同样有参考价值。语音识别、推理、工具调用、语音合成和传输各自独立计时。LiveKit，了解并改善智能体延迟 (https://livekit.com/blog/understand-and-improve-agent-latency)

## 将架构与任务相匹配

多智能体系统带来了上下文隔离和并行探索的优势，但也需要为委托、重复推理、通信、聚合以及额外的错误路径付出代价。依赖结构决定了这种权衡是否值得。

- 紧密耦合的单一推理路径 —— 单个智能体
- 已知的确定性阶段 —— 工作流
- 独立的证据分支 —— 并行工作节点加一个协调器
- 重复的有界转换 —— 代码或批量执行
- 依赖环境的规划 —— 智能体循环
- 在同一评判标准下的独立判断 —— 并行评估器加确定性合并

Google Research 测试了多种协调架构，在并行和顺序任务上发现了不同的结果，同时也发现架构影响了错误在工作节点之间的传播方式。Google Research，迈向智能体系统扩展的科学 (https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)

我要求每个拟议的工作节点拥有一项可分离的任务，并具有明确的输入、输出和合并规则。若专业化分工缺乏这种边界，只会增加一个智能体，而原有的依赖关系依然存在。

容量规划遵循同样的推理逻辑。注册用户数量对到达系统的实际工作量几乎没有说明。我需要了解到达过程、运行时长、内部扇出以及共享资源。

利特尔法则给出了基本关系：

> 系统中的工作量 = 到达率 × 在系统中的时间

更短的服务时间能更早释放执行槽位。运行内的并行工作可能缩短服务时间，但同时占用更多下游槽位。我在公共边界处衡量综合效果。

容量报告描述了一个运行包络：请求到达率与突发形态、活跃运行数量、模型与工具并发数、队列深度、端到端延迟、故障情况、质量结果以及资源余量。

我使用了几个容易混淆的术语。最大观测并发数是测试期间实际发生的数值。最大验证并发数是满足所有目标的最高测试级别。可持续并发数需要稳定的工作负载和运营余量。临界点是指延迟、质量、错误或资源安全超出可接受包络的位置。

负载测试调用已部署的路由。调用内部函数会绕过用户实际遇到的身份验证、网络传输、运行时调度、状态加载、持久化以及代理限制。

我逐步提升并发数，并在每个级别保持足够长的时间以观察队列和尾部延迟。工作负载按预期比例包含简单请求、普通请求和对抗性请求。我分别报告冷启动、热启动、有缓存和无缓存的行为。

在每一步，我记录：

- 已接受、已拒绝、已完成、已超时和已失败的运行；

- 队列时间和执行时间；

- 端到端及各阶段的延迟分布；

- 提供商限流和重试量；

- 工作进程、连接池、内存和数据库压力；

- 缓存命中、未命中和合并请求；

- 模型与工具的扇出；

- 质量结果；

- 取消后仍在继续的工作。

当某项目标失败时，测试即停止。在此之后继续测试可以描述崩溃模式，但我会有意为之，并保护下游服务。每次提交还会获得唯一的运行标识和输入，以防止缓存将并发测试变成对同一结果的重复读取。

## 我优先检查的故障模式

**隐式序列化**表现为循环内部含有 await。即使调用使用独立输入，追踪记录中也不存在任何重叠。

**模型介导的控制流**要求模型批准确定性路由、过滤、计数或格式化。细微的决策不断累积，最终形成推理瓶颈。

**无界扇出**使单个请求快速，而多个并发请求则不稳定。本地延迟持续改善，直到提供商限流将等待转移到重试和队列中。

**末位等待合并**会等待每个分支，包括那些已无法改变结果的可选输出。

**重试放大**发生在嵌套客户端各自应用其重试策略时。一次瞬时故障产生大量尝试，有时甚至发生在调用方截止时间之后。

**上下文累积**将每个原始工具响应保留在历史记录中。后续轮次反复处理那些已不再需要的证据。

**缺乏完整标识的缓存**忽略了授权、来源版本或新鲜度。它在正确性或隐私边界之间返回快速答案。

**全局运行状态**假设只有一个活跃请求。进度、取消操作和最终输出都附加到最近一次写入共享值的运行上。

**流式剧场**在后端阻塞时发出通用活动信号。第一个动画快速出现，而第一条有用信息却迟迟不至。

**仅均值报告**掩盖了尾部情况。少数请求可能将大部分时间耗费在末位等待上，而仪表盘依然显示正常。

**改变质量的优化**减少了工具调用、缩短了搜索路径、丢弃了结果或替换了模型，却未进行非劣性检验。

**超时膨胀**允许请求运行更长时间，并将更高的完成率报告为可靠性提升。失败的定义发生了变化，工作本身并没有变快。

在接触模型之前，我会先检查上述问题，因为标准追踪和负载测试通常可以对其加以确认或排除。

## 我进行优化迭代的方式

我从接入到持久化结果对已部署请求进行全链路追踪，包括父子关系和队列时间。代表性追踪记录转化为依赖图，每个等待节点都标注其原因。

第一轮代码修改用于消除偶发性瓶颈。独立读取并发执行，归约器变为确定性实现，调度器取消无法影响结果的工作。随后，我移除执行固定转换或重复已知计划的模型往返。

下一轮处理数据移动。工具响应缩减为更小的接口，稳定的提示前缀经过整理以便复用，旧状态在没有策略的情况下停止增长。缓存命中与未命中信息进入追踪记录。

并发控制包括：队列边界、准入规则、截止时间、幂等性，以及针对运行、工具和提供商的独立预算。每次调度变更后，我都会重复执行已部署的负载测试，因为孤立运行速度更快，但仍可能损害吞吐量。

一旦执行状态可信，真实的进度事件、重连机制和取消操作就能改善用户体验。

模型变更放在之后进行。推理力度、路由模型和提供商服务层级都能发挥作用，但每一项都会改变成本或推理行为，需要单独评估。如果追踪结果显示某个模型调用从一开始就占据主导地位，我会将该实验提前。顺序服从于证据。

## 我尚不知晓的内容

我不知道一种适用于所有智能体延迟问题的通用架构。研究型、编码型、语音型、事务型和后台型智能体具有不同的依赖关系图，以及不同的部分完成成本。

不存在一个上下文长度阈值可以在不同提供商和模型之间不加修改地沿用。缓存行为、预填充性能、工具模式以及请求路径的其他部分都会影响这个值。

合适的并发限制取决于可分解性、下游配额、突发形态，以及系统为减少墙钟时间所能额外付出的代价。提供商基准测试无法为一个有自身网络路径和流量特征的已部署应用解决这个问题。

自动化质量门控也只能验证其协议所检查的内容。评判者可能与其所评估的系统共享同一失败模式。

这个框架比任何具体设置都更为稳定。智能体是一种具有概率性工作节点的分布式计算。推理与屏障、队列、数据移动、重试、掉队者和协调并列，共同构成延迟的来源。吞吐量取决于运行如何消耗共享容量，而优化仅在结果保留其原有证据和权威性的前提下才成立。

## 参考文献与延伸阅读

以下是我在该主题上认为最有价值的研究论文、提供商工程博客和实践指南。相关文献仍在持续更新中。

1. OpenAI. 延迟优化。输出长度、请求数量、并行性、流式传输及确定性替代方案。(https://developers.openai.com/api/docs/guides/latency-optimization)

1. OpenAI. 模型指导。推理力度、提示缓存、工具设计与状态管理。(https://developers.openai.com/api/docs/guides/latest-model)

1. Anthropic. 构建有效的智能体。工作流、智能体、路由与并行化。(https://www.anthropic.com/engineering/building-effective-agents)

1. Anthropic. 我们如何构建多智能体研究系统。协调器-工作节点执行、并行研究、评估与生产权衡。(https://www.anthropic.com/engineering/multi-agent-research-system)

1. Anthropic. 提示最佳实践。并行工具使用、推理力度与避免不必要的工作。(https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-templates-and-variables)

1. Google Research. 迈向智能体系统扩展的科学。将协调架构与任务结构相匹配。(https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)

1. Kim 等. 面向并行函数调用的 LLM 编译器。感知依赖关系的规划与并发工具执行。(https://arxiv.org/abs/2312.04511)

1. Bian 等. 智能体系统效率的制约因素是什么？模型与环境延迟、缓存与推测执行。(https://arxiv.org/abs/2510.16276)

1. Bai 与 Eisner. 通过提示编排加速语言模型工作流。在模型工作流中复用已编码状态。(https://aclanthology.org/2026.tacl-1.13/)

1. Zhu 等. 先分解后聚合：一种通过并行工具调用实现的高效工具学习方法。图分解与并行工具执行。(https://aclanthology.org/2025.acl-long.1401/)

1. 异步 LLM 函数调用。非阻塞函数执行与中断语义。(https://arxiv.org/abs/2412.07017)

1. AWS。在 Amazon Bedrock 上实现程序化工具调用。通过有界代码执行减少模型往返次数。(https://aws.amazon.com/blogs/machine-learning/implementing-programmatic-tool-calling-on-amazon-bedrock/)

1. AWS。使用 AgentCore Observability 优化生产环境智能体。工具、内存、令牌与调度瓶颈。(https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability/)

1. LangChain。多智能体系统。协调模式及其在模型调用、令牌与并行性方面的权衡。(https://docs.langchain.com/oss/python/langchain/multi-agent)

1. Vercel。智能体技术栈。模型访问、持久化执行与长时运行的智能体基础设施。(https://vercel.com/blog/agent-stack)

1. Vercel。如何构建可扩展的 AI 应用。流式传输、背压、缓存与应用扩展。(https://vercel.com/blog/how-to-build-scalable-ai-applications)

1. LiveKit。理解并改善智能体延迟。面向实时智能体的阶段级可观测性。(https://livekit.com/blog/understand-and-improve-agent-latency)

1. General Compute。评估智能体性能：将延迟作为一等指标。端到端及单步智能体测量。(https://www.generalcompute.com/blog/evaluating-agent-performance-latency-as-a-first-class-metric)