如果你还在按请求数给 LLM Agent Harness 算账，很可能已经漏掉了真正的成本大头：token 成本。Cursor 团队最近公开了一份提示词，目标很具体：不让任务质量下滑，同时压低每个任务的价格加权 token 消耗。他们做了一轮改动，整体 token 成本降了约 7%。数字不算夸张，但在 Agent 反复规划、调用工具、读写缓存、再让子智能体汇报的链路里，7% 不是靠一句“省着点用”换来的。它更像一次系统体检：先找到钱漏在哪，再决定先堵哪个洞。
账本先改，否则优化只是猜
请求数不是任务数
一个任务可能只发一次请求，也可能拆成几十步：读代码、搜索、规划、编辑、跑测试、修复、再总结。你按请求看账单，会把重试和上下文膨胀藏在平均值里。真正该盯的是每任务成本。同一个需求，如果 A 方案请求少但每次塞满上下文，B 方案请求多但每步更短，按请求数比较会得出完全相反的结论。
价格加权，别只看 token 总量
输入、输出、缓存命中、缓存写入，价格不一样。有些模型还有推理 token 的计费方式。把总 token 拉平，等于把不同单价的原料混在一起称重。公开提示词里反复强调价格加权，就是要求团队按真实账单结构归集消耗。否则你优化了输出长度，却让缓存命中率下降，账可能更贵。
质量无损是硬约束
降本最危险的做法，是悄悄降低任务质量。少给上下文、少跑验证、砍掉工具说明，短期 token 下降，长期返工和人工兜底会把钱吃回去。所以先定义质量基线：测试通过率、任务成功率、需要人工介入的比例、平均修复轮次。没有这条约束，7% 毫无意义，甚至可能是负收益。
五个动作，各自解决一类浪费
提示词精简：先删模型不读的礼貌
很多 system prompt 被写成了员工手册。规则重复三遍，示例长得像教程，工具说明把参数逐条复制，安全声明层层叠叠。模型当然能读，但每一次任务调用都要读。精简不是把功能删掉，而是把决策必需的信息留下，把人类读者才需要的铺垫拿掉。你会发现，最贵的提示词往往不是最复杂的，而是最啰嗦的。
工具卸载：别让 Agent 背着全家桶
工具定义本身就是上下文成本。工具越多，模型选择越困难，误调用和空转也越多。所谓工具卸载，是按任务阶段动态挂载工具：搜索阶段只给搜索和读文件，编辑阶段才给写文件，验证阶段再给测试命令。这样既减少输入 token，也降低错误路径。注意，卸载不是禁用，要有清晰边界；一旦任务需要跨阶段回退，得让工具重新出现。
缓存布局：把重复阅读变成折扣
Agent 会反复读同一批文件、同一段规则、同一份 schema。缓存布局做得好，重复上下文就能以更低价格命中；做得差，每次重试都像第一次见。这里没有万能格式。关键是让稳定内容前置、变动内容后置，别让频繁变化的工具结果把稳定前缀打碎。缓存不是省钱补丁，它是上下文架构的一部分。
越不起眼的杠杆，越容易被漏掉
稀疏行号：小格式牵动大成本
稀疏行号听起来像排版细节，却直接影响模型读代码的方式。每行都带行号，会让代码块膨胀；完全不给行号，又会让定位和编辑变难。稀疏行号只在关键锚点标出行号，让模型知道位置，又不为每一行付费。这个改动很小，但在大文件、多轮编辑的任务里，省下来的是重复输入，也是注意力。
子智能体调优：别把助手变成传话游戏
子智能体可以并行探索、隔离上下文、减少主线程负担。但调不好，它会变成传话游戏：主智能体把任务切碎，子智能体各自读一遍背景，再汇总出冗长报告。每一层转发都在烧 token。子智能体调优的重点，是定义清晰的输入输出边界，让它们只带回结论和证据，不搬运原文。该共享的上下文放缓存，该独立的任务再拆。
一轮改一项，归因才清楚
提示词、工具、缓存、行号、子智能体，这五类改动会互相影响。一起上，成本降了也不知道谁立功，成本涨了也不知道谁背锅。更稳的做法是分轮验证：第一轮先精简提示词，第二轮卸载工具，第三轮调整缓存布局。每轮都看每任务价格加权 token 和质量指标。7% 不是一次拍脑袋，而是一串可归因的小改动叠出来的。
执行顺序比技巧清单更值钱
先画 Harness 地图
在改任何 prompt 之前，把 LLM Agent Harness 画出来：模型之外有哪些组件，工具怎么挂载，缓存怎么命中，子智能体怎么通信，重试在哪里发生。地图不必漂亮，但要能回答一个问题：一个典型任务的 token 到底流经哪些环节。没这张图，优化很容易变成局部按摩。
基线要切开看
只看月度总 token，会被任务量、模型切换、用户行为变化搅乱。基线应该按任务类型、复杂度、模型、工具组合切开。比如代码编辑、问答、长文档摘要，它们的成本结构完全不同。切开之后，你才知道哪一类任务值得先动，哪一类动了也省不了多少。
优先级按“省得动”和“省得多”排
有些改动收益大但工程量大，有些改动收益小却能立刻上线。更合理的排序，是先做低风险高确定性的项目：删重复提示词、压缩工具说明、调整缓存前缀。再做需要架构配合的：动态工具挂载、子智能体协议、行号格式统一。最后才碰那些可能影响质量的高风险优化。顺序错了，团队会在验证阶段耗尽耐心。
那份公开提示词，真正的骨架是什么
目标函数只有一句
降低每个任务的价格加权 token 成本，同时不降低任务质量。注意，是每个任务，不是每次请求；是价格加权，不是原始 token 数；是不降低质量，不是先降了再说。这一句写清楚，后面的取舍才有统一标准。否则每个人都在优化自己手里的指标，合起来可能推高总账。
约束条件先写在前面
质量约束、延迟约束、稳定性约束，最好在优化开始前就写进提示词。比如：不能减少必要验证步骤，不能增加人工复核比例，不能把错误率转移给下游。约束不是限制创造力，而是防止团队用隐藏成本换表面数字。Agent 系统尤其如此，少一次工具调用可能省 token，但多了三次重试就全还回去了。
动作要能复现，别只留心得
公开提示词的价值，不在于给出某个神奇模板，而在于把动作写成可复现流程：映射 harness、测量基线、按优先级实施、验证质量。心得可以启发人，流程才能让团队复用。尤其是当模型、工具、价格都在变，今天的技巧明天可能失效，但测量和归因的方法不会过期。
7% 之后，别急着庆祝
把 Harness 当成产品来维护
很多团队把模型当产品，把 Harness 当胶水。事实相反，Agent 的用户体验和成本，大量由 Harness 决定。工具怎么暴露、上下文怎么裁剪、缓存怎么布局、子智能体怎么协作，这些都是产品决策。把 Harness 当成产品，就会有版本、有指标、有回归测试，而不是散落在几个 prompt 文件里。
下一轮盯延迟和稳定性
token 成本降下来后，延迟和稳定性会变得更显眼。缓存布局可能影响首 token 时间，工具卸载可能增加切换成本，子智能体并行可能带来协调开销。下一轮优化不能只看账单，要把延迟分位数、重试率、失败恢复时间一起看。省钱的改动如果让用户等更久，最终还是贵。
降本不是一次性运动
模型价格会变，上下文窗口会变，工具生态也会变。今天有效的 7%，下个季度可能被新模型或新任务形态抹平。真正该留下的是一套习惯：按任务计量、按价格加权、先测基线、再动结构、质量无损。Cursor 团队这份公开提示词值得读，不是因为它保证了 7%，而是因为它把 Agent 降本从玄学拉回了工程。
