当你的 AI 智能体全天候开着时，很容易快速烧掉大量 token。有一段时间，大家就是这么使用我们的智能体框架的。可惜，成本很快就累积起来了。
所以无节制烧 token 的时代结束了。无论你的编程框架是按 token 还是按额度计费，成本都会累积。让我来展示几种帮你降低 token 成本的方法！我在示例中使用的是 Kiro，但你可以用任何你喜欢的工具。
本文很多内容基于 Laura Salinas 的文章把 Kiro 的免费额度用到极限。她在 Kiro 的免费额度上构建了一个项目，并追踪了她的额度都花在了哪里。值得一读。
我还做了一个视频，覆盖了全部五点。如果你更想看视频，可以去看看：
（坦白说：我是 AWS 的开发者布道师，而Kiro归 AWS 所有。我在视频里用的就是它，所以下面的示例也用它。）
1. 简单任务用更便宜的模型
这一点有点显而易见，但你不该所有事情都用同一个前沿模型。修个快速 bug 或者重命名一个 prop，不该需要最新最强的模型。
在 Kiro 中，模型选择器会显示每个模型的额度倍率，一切都以 Auto 的 1.0x 为基准。开源权重模型处在便宜的一端。Qwen3 Coder Next 是 0.05x，MiniMax M2.1 是 0.15x，DeepSeek 3.2 是 0.25x。前沿模型 Opus 5.5 是 2.0x，还有几个模型比这更高。
这些模型文档说明了这意味着什么。一个在 Auto 上花费 10 额度的任务，在 Opus 5.5 上要花 20，在 Haiku 4.5 上花 4，在 Qwen3 Coder Next 上花 0.5。同一个任务，差距高达 40 倍。
如果你的模型支持，你还可以调低推理强度。文档说，更低的强度等级会带来更快、更短的响应，并消耗更少的额度。
提醒：倍率会随着新模型出现而变化，所以在选定模型前先查看模型页面。两个倍率相同的模型，在同一个任务上仍可能消耗不同数量的额度，因为 token 数量和思考深度各不相同。
这里要记住规格驱动开发。我会在第 3 点里再回来讲它，因为那正是混合使用模型的地方。
2. 把 token 规则写进你的 steering 文件
Steering 文件是 markdown 文件，位于.kiro/steering/Kiro 会将其作为持久上下文加载，因此你不必在每个会话中重复自己。以下是我在自己的文件中使用的一些 token 规则。你可以完全照这样写，Kiro 会尝试遵循它们：
---
inclusion： always
---
# Token 规则
- Don't create unnecessary files.
- Don't create tests unless I ask you to.
- Try to save on token usage.
将其保存为.kiro/steering/token-rules.md。inclusion: always是默认模式，因此它会加载到每一次交互中。front matter 必须是文件中的第一项内容，其上方不能有空行。有了这些规则，我就知道不会收到一堆我从未要求的文件或测试。
Laura 在她的构建中就遇到了这种情况。没有 steering 文件时，DeepSeek 生成了她不需要的验证文件和摘要 markdown，而这些都消耗了额度。她建议的 steering 规则包括“不要创建摘要 markdown 文件”和“使用最少的代码，不要样板代码”。
Always-on steering 也会随每个请求一起加载，所以要保持该文件简短。任何特定于框架的内容都可以使用fileMatch，它只会在你处理匹配的文件时加载该文件：
---
inclusion： fileMatch
fileMatchPattern： "components/**/*.tsx"
---
# React 组件规则
- Use function components and hooks.
- Type props with an interface in the same file.
还有另外两种模式。manual仅当你用#file-name在聊天中引用某个文件时才加载它，而auto在你的请求与其描述匹配时加载它。steering 文档涵盖了全部四种模式。
3. 使用双模型进行规范驱动开发
如果你要构建一个需要一些预先思考的功能，而不只是快速修复 bug，那么规范驱动开发就是正确的方式。一个 Kiro spec 会经历三个阶段（需求、设计和任务），并将requirements.md、design.md和tasks.md写入.kiro/specs/。
需求和设计阶段是进行艰难思考的地方，因此这也是更强的模型发挥其价值的地方。一旦你有了扎实的需求和设计文档，实现阶段就不需要最新的前沿模型了。更便宜的模型在处理清晰的任务列表时表现相当不错。你或许可以试试。
要进行切换，请在开始运行任务之前更改模型选择器。模型文档说，你的选择会应用于对话中之后的所有消息。任务可以一次运行一个，也可以一次性全部运行，因此你可以在让更便宜的模型运行其余任务之前，先检查它在第一个任务上的工作。
有关各阶段的更多内容，请参见specs 文档。
4. 让 ESLint、Prettier 和 hooks 做确定性的工作
如果一项工作有确定性的答案，就不要花钱让大语言模型去解决它。格式化和 lint 修复就是这类工作。Prettier 每次都会给你相同的输出，eslint --fix也是如此。当你让智能体去做这件事时，你要为它读取文件、推理并写出一个工具本可以瞬间生成的 diff 而付费。
Laura 的文章表达了同样的观点。她建议使用在保存时自动 lint 或自动格式化的 hooks，这样你就永远不会花额度让智能体去修复风格问题。
从package.json中的脚本开始。这还包括下面更靠后的一个用于 commit hook 的lint-staged块：
{"scripts"：{"lint"："eslint ."，"lint:fix"："eslint . --fix"，"format"："prettier --write ."}，"lint-staged"：{"*.{js,jsx,ts,tsx,vue}"：["eslint --fix"，"prettier --write"]}}我有一个 hook，每次我做完某件事时都会运行 Prettier 或我的 Husky 规则，这样我就不会在它上面浪费 token。在 Kiro 中，hooks 是位于.kiro/hooks/中的 JSON 文件。下面这个会在智能体完成其回合时进行 lint 修复和格式化：
{"version"："v1"，"hooks"：[{"name"："Lint and format when the agent finishes"，"trigger"："Stop"，"action"：{"type"："command"，"command"："npm run lint:fix && npm run format"}}]}将其保存为.kiro/hooks/format-on-stop.json。Stop触发器会在智能体完成其回合时触发，而command动作会在你的项目根目录中运行一个 shell 命令。hook actions 文档说 shell 命令动作不消耗额度，而智能体提示动作会消耗，因为它们会启动一个新的智能体循环。所以对于格式化，选择command。
如果你更愿意在每次保存时运行，hooks 文档展示了一个带匹配器的PostFileSave触发器，类似"matcher": "\\.(ts|tsx|vue)$"。文件触发器只在智能体所做的更改上触发，而不会在你自己的编辑上触发。
对于提交，Husky 加上 lint-staged 会在暂存文件上运行相同的工具。
npm install --save-dev husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit
husky init会创建.husky/pre-commit并向prepare添加一个package.json脚本。echo这一行将默认的npm test替换为npx lint-staged，它会从上面的package.json读取配置。
5. 留意你的上下文窗口
最后一个建议是仔细检查你的上下文使用情况。在 Kiro 中，聊天面板里的上下文使用量计量器会显示你距离模型上限有多近。
这很重要，因为在每个回合，每次你与模型来回交互时，之前的聊天历史都会被再次发送。会话越长，每条消息携带的上下文就越多。
MCP 服务器会加剧这一点，因为它们的工具定义也会占用上下文。KiroPowers 文档具体量化一下。五个连接的 MCP 服务器可能意味着 100+ 个工具定义和 50,000+ 个 token，约占你上下文窗口的 40%，而这还发生在你发出第一条提示之前。不同的运行框架对此的处理方式可能不同，有些会使用搜索工具来帮助防止 MCP 服务器造成的上下文膨胀例如，Kiro Powers 只会在你的对话提到相关内容时才加载它们的工具。效果可能因人而异，所以请关掉你当前项目用不到的 MCP 服务器。
然后，当你转向新任务时，开启一个新会话。上一个任务的历史对下一个任务没有帮助，而且它会在每一轮都被一并发送。在 Claude Code 中，/clear就会这样做。它会开启一个新会话并保留上一个会话，以便你之后可以恢复它。Kiro 也会自动压缩长会话，但为不相关的工作开启一个全新会话能让上下文从一开始就保持精简。
总结
再次感谢 Laura Salinas将 Kiro 的免费套餐推向极限。里面还有更多我没在这里提到的技巧，比如写一个具体的第一条提示，以及把智能体指向包含#File的文件。如果你想看这些技巧的实际演示，视频版本在顶部。
如果我漏掉了哪一个，欢迎在评论区告诉我。