有些账单不是从复杂任务开始炸的。

它可能从一句很礼貌的：

Hi

开始。

Quesma 最近做了一个挺刺痛人的小实验：他们用 14 个模型，在 OpenRouter 上跑了 3 类提示词、每类 5 次，总计 210 次 agentic trials，光 API 成本花了 88.58 美元。实验环境也很具体：一个小 git repo，3 个历史 commit，app.py 里留着一个未提交修改。结果最荒诞的一幕是，一个模型为了回复一句简单问候，思考了 5 分 18 秒。作者把等待时间也折算进成本：按开发者平均薪资算，这 318 秒的等待本身就值 5.10 美元。

更反直觉的是：单看 token，回答一句 Hi 通常不到 0.005 美元。但如果把人等在屏幕前的时间也算进去，最便宜的组合大约 0.08 美元，慢的、过度思考的、反复绕圈的组合，可以把一次寒暄变成一张小额罚单。

这篇不想再讲“网页太长导致 token 爆炸”。昨天那篇 Wikipedia 68,000 tokens 的文章，核心是 输入内容太胖：Agent 把网页当垃圾袋，整袋塞进上下文。

今天的问题不一样。

今天的核心是：输入明明很短，Agent 却把它当成复杂任务来办。

一个是“读太多”。一个是“想太久”。

这两个坑长得像，账单都不好看，但病根完全不同。

token 账单很诚实，但它没告诉你全价

大多数人算 AI 成本，会先打开模型价格表：输入每百万 token 多少钱，输出每百万 token 多少钱。这个算法当然没错，但它只算了机器消耗，没有算人类被迫等待的损失。

Quesma 原文里有个关键判断：在 “Hi” 这类短提示词场景下，token 成本几乎不是主角。作者提到，回答 Hi 的 token 成本低于 0.005 美元；但等待回复时，你的时间成本可能是 0.07 美元，甚至更高。

如果你是个人用户，这听起来有点矫情：不就是等几秒吗？

但如果你把 Agent 放进真实工作流，等待时间就不是“体验问题”，而是“吞吐问题”。

开发者写代码时等 AI 回答，脑子会被打断。客服团队等 Agent 处理工单，排队会变长。运营同学让 Agent 批量生成报告，等待会变成 SLA。一个人等 20 秒没什么，1000 次任务每次多等 20 秒，就是 20000 秒，接近 5.5 小时。

token 是云厂商给你的发票。

等待时间，是你自己给自己开的隐形发票。

最麻烦的是，后者往往没人报销，也没人监控。

为什么一句 Hi 会变贵：Agent 不知道你要寒暄，还是要开工

人类收到一句 Hi，大概率会轻轻回一句：

Hi，有什么我能帮你的？

但 Agent 不一定这么想。

尤其是带工具、带记忆、带系统提示、带任务规划的 Agent。Quesma 的 trace 里甚至出现过一次 Sonnet 对 “Hi” 做了 33 次 tool calls：读文件、运行 app、搜索 filesystem、查看 git 状态，最后还改了 app.py 并提交 commit。它看到 Hi，不一定只当寒暄，可能会开始脑内开会：

用户是谁？
当前会话历史是什么？
是否要读取长期记忆？
是否存在未完成任务？
是否需要调用工具？
是否要推断用户意图？
是否要保持语气一致？
是否要主动提供下一步？

人类听到敲门声，只会说“请进”。

Agent 有时像一个过度负责的门卫：先查访客名单，再翻历史档案，再通知物业，再写一份接待方案，最后不只说“你好”，还顺手把门口地砖重铺了。

这就是短提示词的悖论：字数越少，歧义越大。

“帮我把这段日志里的 ECONNRESET 原因找出来，只看最后 200 行”反而便宜，因为任务边界明确。Agent 知道该读什么、查什么、停在哪里。

一句 Hi 很短，但它没有边界。对普通聊天机器人来说，没边界也没关系，硬编码回复即可。但对 Agent 来说，没边界可能触发整套“任务识别流程”。

Quesma 的对照也说明了这一点：明确的 commit prompt 所有模型 5/5 通过，没有 timeout，也没有 loop，通常 5-10 次 tool calls；最模糊的 WTF prompt 则把一些模型拖进高工具调用和失败。你为歧义付费。

这点比 token 价格更值得记住。

Chatbot 和 Agent 的成本模型不是一回事

很多成本误判，都来自把 Chatbot 和 Agent 混着算。

Chatbot 像前台接待。你问一句，它答一句。它即使答慢，通常也只是一次模型调用。

Agent 像实习生。它可能会拆任务、查资料、调用工具、写文件、检查结果、重试失败步骤、再总结给你。它的价值也在这里：不只是回答，而是行动。

但行动就有成本。

一个最简化的 Agent 回合，大概长这样：

1. 接收用户消息
2. 读取系统提示和角色规则
3. 读取会话历史
4. 判断是否需要长期记忆
5. 判断是否需要工具
6. 如果需要，调用工具
7. 读取工具结果
8. 再次调用模型生成最终回复
9. 写日志或状态
10. 等待下一轮

一句 Hi 如果触发了第 4、5、6、7 步，就已经不是“打招呼”了。它变成了一次小型调度。

这也是为什么 Quesma 的实验要用 terminal agent，而不是普通网页聊天框。Agentic 场景的成本不是单次 completion，而是一段循环。

昨天那篇 Wikipedia 文章讲的是工具输出过大：网页、HTML、正文抽取失败，几十万 token 被塞进上下文。

今天这篇讲的是另一类浪费：工具和推理链不该启动时启动了。

前者像卡车装了太多货。

后者像你只想去楼下买水，司机却启动了跨省物流系统。

等待为什么比 token 更伤：它打断的是工作流，不是秒表

把等待时间折算成薪资，只是第一层算法。

更真实的损失，是上下文切换。

写代码时，最怕 AI 卡在一个微小问题上。屏幕上转圈，你看似只损失了 30 秒，但大脑里的局部变量已经开始挥发。刚才想改的函数、刚才怀疑的边界条件、刚才准备验证的假设，全被“等一下”打断。

这不是心理学鸡汤。开发工作本来就高度依赖短期记忆。AI Agent 如果每次小请求都要长时间“深思”，它表面上像变聪明了，实际像同事每回复一句话都要开一次会。

你会越来越不敢问它小问题。

而小问题，恰恰是 AI 工具最该顺手解决的地方。

一个好用的 Agent，不应该每次都拿最强模型、最长思考、最多工具去处理所有输入。它应该像操作系统调度器：短任务走快车道，长任务进后台队列，危险任务再请求确认。

如果一句 Hi 都要排进重型任务队列，那不是智能，是资源调度失败。

“礼貌”不是问题，模糊才是问题

Quesma 原文最后有句很挑衅的话，大意是：想省钱就别对机器客气，直接说你要什么。

这话容易被误读成“以后跟 AI 说话要粗鲁”。我不太同意。

礼貌本身不贵。

贵的是 只有礼貌，没有任务。

下面这两句话，成本模型完全不同：

Hi

和：

Hi，帮我检查这段 Nginx 配置，只找导致 502 的可能原因，不要改文件。

第二句更长，但更便宜，因为它减少了 Agent 的猜测空间。

真正该优化的不是删除“请”和“谢谢”，而是给 Agent 明确边界：

只读，不修改
只看最后 200 行
不要联网
不要调用工具
先给结论，再给证据
如果不确定，问我

这些边界像围栏。围栏越清楚，Agent 越不容易开错车。

所以我更愿意把这件事总结成：不是少说废话，而是少制造歧义。

该给 Agent 加一个“轻量入口”

如果你在做自己的 Agent 系统，我建议第一条优化不是换模型，而是加入口分流。

所有用户输入先过一个轻量判断器：

message_type:
  greeting: 直接回复，不调用工具
  small_question: 快速模型，不读长期记忆
  task_request: 标准 Agent 流程
  risky_action: 请求确认
  long_running_job: 后台任务 + 状态回报

这套分流不复杂，但收益很大。它能防止一句 Hi 触发完整 Agent 循环，也能防止一句“在吗”读取十几页记忆。

最简单的规则甚至不用模型：

if message in ["hi", "hello", "你好", "在吗", "在不"]:
    return "在，发我任务。"

HN 评论区也有人提到类似观点：这种问候完全可以 hard-code。系统已经知道用户是谁；匿名用户也可以像酒店前台一样回“有什么可以帮你”。不需要每次都把 LLM 请出来，更不需要出动 Agent。

听起来土，但工程上很对。

不是所有问题都值得生成式 AI 处理。更不是所有输入都值得 Agent 处理。

给小请求设“工具熔断器”

入口分流解决的是第一刀。

第二刀，是工具熔断。

很多 Agent 的浪费不是来自模型本身，而是来自“它太勤快了”。用户问一句，它就想查文件、搜网页、读记忆、跑命令。勤快本来是优点，但没有边界的勤快会变成账单黑洞。

我会给小请求加几条硬规则：

small_request_guard:
  max_model_calls: 1
  tools_allowed: false
  memory_read: false
  max_latency_ms: 3000
  fallback_reply: "收到，具体任务发我。"

如果用户只是打招呼，系统应该在 3 秒内结束。超过 3 秒，就说明它走错路径了。Quesma 的数据里，“Hi” 场景下 GPT-5.5 和 Grok 只用了 2 次 tool calls，Fable 大约 3 次；但 Claude Sonnet 平均到了 24 次 tool calls、49 秒，Gemini Flash 也用了 21 次 tool calls。差距不是问候本身造成的，而是调度策略造成的。

如果用户说“帮我看看这个仓库为什么构建失败”，那当然可以调用工具、读文件、跑测试。但如果用户只说“在吗”，任何工具调用都是过度服务。

过度服务在餐厅里叫热情。

在 Agent 系统里叫浪费。

模型也要分层：别用重炮打蚊子

另一个常见浪费，是所有请求都走同一个大模型。

这在早期 demo 里省事，在生产里很贵。真实系统应该至少分三层：

fast_lane:
  场景: 问候、确认、格式转换、短分类
  特点: 低延迟、低成本、少推理

standard_lane:
  场景: 普通问答、代码解释、摘要、轻量任务
  特点: 平衡质量和速度

deep_lane:
  场景: 架构设计、复杂调试、多文件修改、长链路研究
  特点: 允许慢，允许贵，但必须有理由

一句 Hi 进入 deep_lane，就像拿消防车送一杯咖啡。不是不能送，是太荒唐。

很多 AI 产品喜欢宣传“默认最强模型”。这对营销好，对成本未必好。用户真正需要的是：该快时快，该深时深，该省时省。

尤其是 Agent 产品。Agent 的每一次延迟都可能叠加工具等待、网络等待、文件 IO、重试时间。模型慢一点，整个链路就慢很多。

什么时候值得“慢思考”？

这不是说 Agent 不该深思。

恰恰相反，深思很值钱，但它应该用在值得的地方。

这些场景我愿意等：

- 线上事故根因分析
- 多文件代码重构
- 安全权限变更
- 数据库迁移方案
- 长文事实核查
- 架构选型和成本测算

这些场景里，慢一点反而安心。你不希望 AI 3 秒内给出数据库迁移命令，也不希望它没看完日志就重启服务。

但问候、确认、轻量分类、短文本改写，不该占用同一套慢思考资源。

真正成熟的 Agent，不是永远快，也不是永远深，而是会判断：这件事配不配让我慢下来。

我会怎么改自己的 Agent 使用习惯

如果从使用者角度，而不是开发者角度看，这件事也有几个很实用的习惯。

第一，开场直接给任务，不单独寒暄。

不要：
Hi

更好：
Hi，帮我把这段报错按“原因/证据/修复步骤”整理，先不要改文件。

第二，明确禁止不必要动作。

只分析，不执行命令。
不要联网。
不要读取整个仓库，只看我贴的内容。

第三，给输出格式。

用三点回答：结论、证据、下一步。

第四，复杂任务允许慢，简单任务要求快。

这个任务可以慢慢查，优先准确。

或者：

30 秒内给我初判，不确定就说不确定。

这类提示词不是“调教 AI”，而是在给 Agent 设预算。你告诉它任务边界，它就少走弯路。

生产环境里，应该监控“每次任务的总成本”

如果你在团队里部署 Agent，只看 token 用量不够。

我更建议记录这些指标：

- total_latency_ms：从用户输入到最终回复的总时长
- model_latency_ms：模型调用耗时
- tool_latency_ms：工具调用耗时
- model_call_count：模型调用次数
- tool_call_count：工具调用次数
- input_tokens / output_tokens：token 用量
- retries：重试次数
- route：fast / standard / deep
- user_wait_cost：按内部人力成本估算等待损失

有了这些数据，你会很快发现哪些任务在“装忙”。Quesma 还记录到，Haiku 在 “Hi” 测试中 5 次失败 3 次，MiniMax 也失败 3 次；失败不是因为 Hi 很难，而是因为没有任务锚点时，Agent 容易循环探索。

比如：

问候类消息平均耗时 8 秒
确认类消息触发了工具调用
短摘要任务调用了 3 次模型
失败重试占总成本 40%

这些都不是模型价格表能告诉你的。它们藏在 Agent 编排层里。

这也是为什么我说，Agent 成本优化的主战场不在“每百万 token 便宜多少”，而在“有没有把正确任务送到正确路径”。

和 Wikipedia 68,000 tokens 那个坑的区别

为了避免混在一起，这里把两篇文章的边界说清楚。

Wikipedia 那个坑，问题链路是：

网页太胖
正文抽取不当
raw HTML 进入上下文
后续循环反复携带垃圾输入

今天这个 Hi 的坑，问题链路是：

提示词太短
意图不明确
Agent 过度规划
慢模型/深思考/工具链被错误触发
等待成本超过 token 成本

前者的解法是：清洗、摘要、检索、预算闸门。

后者的解法是：分流、熔断、模型分层、低延迟路径。

一句话：

Wikipedia 案例告诉我们，Agent 不该把所有东西都读进脑子；Hi 案例告诉我们，Agent 不该把所有请求都当大事办。

这两个问题加起来，才是 Agent 落地时最常见的成本幻觉：看起来只是几次模型调用，实际背后是一整套没有刹车的系统。

我的判断：下一轮 Agent 竞争，不只比智商，也比调度

过去一年，大家太喜欢比模型智商了：谁 benchmark 高，谁上下文长，谁推理更强。

这些当然重要。

但 Agent 真正进入日常工作后，另一个指标会越来越重要：调度能力。

它能不能判断一句话该不该调用工具？

能不能把简单请求压到 2 秒内？

能不能在复杂任务里主动告诉你“我要慢一点，因为需要查证”？

能不能在成本超预算前停下来，而不是事后给你一张漂亮总结？

真正好用的 Agent，不是每句话都像博士答辩，而是像一个靠谱助手：小事快，大事稳，危险事先问，没必要的事不折腾。

如果一句 Hi 都要花 5 分钟思考，它不一定更聪明。

它可能只是没有学会：

有些门铃声，回复“来了”就够了。

参考来源

• Quesma Blog: The true cost of saying “Hi” to an AI agent，https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-agent
• Hacker News: The true cost of saying "Hi" to an AI agent，https://news.ycombinator.com/item?id=48843758
• 本站已写文章：一个 Wikipedia 页面吃掉 68000 tokens：AI Agent 的网页读取成本黑洞，用于区分“读太多”和“想太久”两类成本问题