Cost and Latency：Agent 不是能跑就够了

今天先记住

Cost and Latency（成本与延迟）不是上线后才看的账单问题，而是 Agent 设计时就要参与决策的约束：该不该查记忆、要不要调用工具、能不能多轮重试、是否需要人工确认，都会改变一次任务花多少钱、等多久、失败时浪费多少。

它在大地图里的位置

今日坐标

横跨整条链路 → Cost and Latency

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

成本和延迟贯穿整条链路。上下文塞得越多，模型输入越贵；工具越多，等待越长；评估和重试越细，可靠性边界更清楚，但也会多花一次或几次执行成本。

它到底是什么

成本主要来自四类：模型 token、外部工具调用、检索 / 存储、以及人工介入。延迟也不只是一句回答生成多久，而是排队、检索、模型推理、工具执行、重试、审批、最终输出的总和。

Agent 比普通 Chatbot 更容易失控，是因为它不是一次问答。它可能先读记忆，再查资料，再跑命令，再根据观察结果修正。每多一步，都多一个花钱点和等待点。

为什么 Agent 里会用到它

一个系统如果只追求“尽量聪明”，很容易变成所有问题都走重流程：简单问候也检索长期记忆，普通解释也联网，失败后无限重试。表面上更认真，实际上会让用户等、账单涨，还增加误触工具的机会。

好的 Agent 要把任务分级：低风险、低价值、信息充分的任务走短路径；高风险、会改变外部状态、缺关键上下文的任务才走完整路径。成本和延迟不是要你少做事，而是逼你判断“这一步有没有必要”。

怎么判断它有没有用

如果用户要的是一句稳定常识，不要默认检索、联网和多工具链。
如果任务会写文件、发消息、提交代码，允许更高延迟，但要把确认、检查和失败回滚算进流程。
如果一次失败会导致重复调用昂贵工具，就要设置最大重试次数和可观测的失败原因。
如果系统平均很快但偶尔卡几十秒，要看是哪一步长尾：模型、检索、工具、网络，还是人工审批。

一个小例子

txt

Input:
用户说：“把今天的 AI Agent Daily 发布出去。”

Process:
短路径：读取框架和前一篇标题 -> 生成当天 Markdown -> 检查敏感内容 -> git add 指定文件 -> commit -> push。
不走的路径：不跑全站 build，不手动 vercel，不把无关目录加入提交。

Output:
生成 /ai-agent/2026-07-29 页面。
成本被控制在必要的文件读取、一次写入、一次提交和一次 push。
延迟不被全站构建和手动部署放大。

这个例子可以用来解释成本控制：不是偷工减料，而是把“必要动作”和“看起来很完整但这次不需要的动作”分开。

常见误区

以为更长上下文一定更好。无关上下文会增加成本，也可能干扰决策。
以为多调用工具就是更可靠。工具调用只有在能减少猜测或完成外部动作时才值得。
只看平均响应时间。Agent 系统更要看长尾延迟，因为用户最容易被偶发卡死打断。
把重试当万能补救。没有失败分类的重试，只是在重复花钱。

今天自测

一个 Agent 任务里，哪些步骤会同时增加成本和延迟？
为什么“简单问题也走完整 Agent 流程”通常不是好设计？
如果一个 Agent 偶尔很慢，你会先排查模型、工具、检索，还是人工审批？为什么？

Cost and Latency：Agent 不是能跑就够了 ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​