1. 项目概述：当成本成为首要设计约束
在AI代理领域，我们常常沉迷于追求更高的智能、更复杂的推理链和更炫酷的自动化能力。然而，一个残酷的现实是：一个失控的AutoGPT循环，可以在一个下午轻松烧掉300美元。大多数框架将成本视为部署后的监控指标，而非设计之初的核心约束。这导致了许多惊艳的实验室原型，一旦投入真实生产环境，便会因不可预测的账单而迅速夭折。
我们团队在过去几个月里，进行了一场反向实验：将每日运营成本硬性限制在2美元，作为AI代理系统架构设计的首要约束。这个名为Veltrix的自主代理，需要管理三个真实业务（一个AI工具平台、一个露营装备电商网站和个人事务），并在如此极端的预算下稳定运行。听起来像天方夜谭？起初确实如此。第一周，日均成本高达4.42美元，甚至出现过单日13.15美元的“灾难”。但正是这些失败，驱动了我们构建一套名为“成本优先代理架构”的体系。最终，在第三周，我们将日均成本降至1.46美元，总任务成功率维持在99.7%。这一切的核心，是一个四层模型路由层级、渐进式降级和本地模型脚手架的组合拳。
这不仅仅是关于省钱。我们发现，为成本而设计，反而催生出更具弹性、更可观测、更接近生产就绪的系统。当你不得不问“这个任务真的需要价值15美元/百万令牌的Claude Opus吗？还是免费的本地14B模型就能搞定？”时，你会被迫做出更清晰、更稳健的架构决策。本文将详细拆解我们如何实现从日均13美元到1.5美元的蜕变，分享其中每一个具体的机制、踩过的坑和验证过的模式。
2. 系统架构核心：四层模型路由与成本感知决策
2.1 整体架构与运行环境
Veltrix的核心是一个运行在WSL2实例上的系统服务（systemd service）。硬件配置是一台搭载RTX 5060 Ti（16GB显存）和48GB RAM的消费级机器。代理通过Telegram接收指令，执行一个标准的ReAct（Reason-Act-Observe）循环，并接入超过20个服务集成，包括GitHub、Notion、Zoho Mail、Vercel、Brevo、Supabase、Stripe等，以管理三个业务组合。
核心循环本身并不复杂：接收消息 -> 分类任务复杂度 -> 路由到合适的模型层 -> 在有限迭代循环中执行工具调用 -> 对结果评分 -> 记录一切到SQLite。真正的精髓在于围绕这个循环构建的“成本控制机器”：预算感知的路由器、降级状态机、上下文压缩和重试策略。正是这些机制，使得在极端资源限制下的稳定运行成为可能。
注意：选择WSL2作为生产环境带来了独特的网络可靠性挑战，我们将在后续章节专门讨论。如果你的部署环境可控，更推荐使用裸金属服务器或成熟的容器平台（如Kubernetes），以避免我们遇到的一些底层网络问题。
2.2 四层模型路由层级详解
路由器的核心是一个四层模型成本层级，其选择逻辑严格遵循预算状态：
第一层：本地模型（零边际成本）
- 模型：通过Ollama在本地GPU运行的Qwen2.5-14B。
- 成本：$0 / 调用（仅电费）。
- 适用任务：分类、邮件分类/草稿、格式化、摘要、内部笔记、代理间通信。这些是经过实证验证、本地模型能产出可接受结果的任务类型。
- 生产数据：在观察期内处理了101次调用，API成本为零。
第二层：预算云模型（约$0.002/次）
- 模型：通过OpenRouter调用的Arcee AI Trinity-Large-Thinking（输入$0.22/百万令牌，输出$0.85/百万令牌）。
- 成本：极低，作为“预算警戒线”后的主力降级选择。
- 适用任务：需要工具调用但复杂度不高的结构化工作，以及当每日预算消耗超过50%时，所有非本地任务的强制降级目标。
- 生产数据：10次调用，平均质量评分3.6/5。
第三层：主力云模型（约$0.034/次）
- 模型：Claude Sonnet 4（输入$3/百万令牌，输出$15/百万令牌）。
- 成本：中等，是系统处理中等复杂度任务（多步推理、内容生成、大部分工具调用）的“主力军”。
- 适用任务：被分类为“中等”复杂度的任务。
- 生产数据：1,192次调用，占总调用量的76.3%，提示缓存命中率高达80.4%。
第四层：前沿模型（约$0.08/次）
- 模型：Claude Opus 4（输入$15/百万令牌，输出$75/百万令牌）。
- 成本：高昂，仅用于需要超长推理链的“困难”复杂度任务。
- 生产数据：在观察期内，由于预算限制，几乎没有任务能触发此层级的路由。
路由决策由selectModel()函数执行，它按顺序检查以下规则：
- 任务类型硬路由：对于
simple（简单查询）、internal（内部通信）、note（笔记）、classify（分类）、summarise（摘要）、email（邮件）、format（格式化）等任务，无条件路由到本地模型。这是基于大量实验得出的结论：对于这些纯文本生成/处理任务，Qwen2.5-14B的质量足以满足生产要求。 - 结构化工作路由：对于
tool（工具调用）和search（搜索）任务，默认路由到Trinity（第二层），因为它比本地模型具备更强的推理和工具调用能力，同时成本极低。 - 预算状态检查：对于需要预算感知的
medium（中等）和hard（困难）任务：- 预算消耗 < 50%（0-$1）：使用路由历史中该任务类型表现最佳的模型（通过学习路由器查询），默认回退到Sonnet。
- 预算消耗 50%-100%（$1-$2）：强制将所有任务降级至Trinity。
- 预算消耗 > 100%：完全屏蔽Sonnet和Opus，Trinity成为最高可用层级。
- 速率限制：单日API调用超过30次（即使预算未超），将触发强制Trinity路由。这旨在捕获那些尚未烧光预算但已表现出病态调用模式的循环。
- 学习路由器：对于没有硬性路由规则的任务，系统查询
routing_history表，寻找该任务类型历史上平均质量评分≥3且至少有5次观察记录的最佳表现模型。
这种设计的关键在于，路由决策是在调用发生前做出的，而非像FrugalGPT的级联方法那样依次尝试更便宜的模型。这避免了“为失败付费”——即先用昂贵模型失败，再用便宜模型重试，导致成本叠加。
2.3 成本估算与追踪：提示缓存的巨大威力
每个API调用的成本都通过一个静态定价表实时计算。公式考虑了提示缓存（Anthropic等模型支持）：成本 = (未缓存输入令牌数 * 输入费率 / 1,000,000) + (缓存输入令牌数 * 缓存读取费率 / 1,000,000) + (输出令牌数 * 输出费率 / 1,000,000)
提示缓存是我们的“成本杀手锏”。我们将系统提示拆分为两部分：
- 稳定前缀：身份定义（
SOUL.md）、代理规则（AGENTS.md）、工具文档（TOOLS.md）、高频经验教训。这部分在会话中极少变化，我们为其添加了cache_control: { type: 'ephemeral' }注解，使其能够在多次调用间被缓存。 - 动态后缀：当前上下文（
CONTEXT.md）、日期、活跃业务组合状态。这部分每次调用都可能不同，从不缓存。
生产数据显示，Claude Sonnet 4的提示缓存命中率达到80.4%。这意味着有2500万令牌是通过缓存读取的（成本约$0.30/百万令牌），而非全价读取（$3.00/百万令牌）。仅此一项，就将系统提示的成本降低了约72%，在整个观察期内估计节省了7.27美元。对于长期运行、频繁调用的代理，精心设计可缓存的提示结构是降低成本的必由之路。
2.4 生产级ReAct循环的适配
我们实现了标准的Reason-Act-Observe循环，但加入了多个生产环境必需的适配：
有界迭代：循环上限为20次迭代（在降级状态下会减少）。每次迭代：调用LLM、检查工具调用、执行工具、评分、检查预算阈值。
上下文压缩：当令牌使用量达到模型上下文窗口的70%时，系统会自动压缩对话历史。它会从较早的消息中提取用户请求、已采取的行动、成功结果、遇到的错误和使用的工具，将其替换为一个结构化的快照，并仅保留最近的6条原始消息。这能在保留意图和状态的同时，回收大量令牌预算。
回合级质量评分：每次工具执行回合后，系统根据工具调用成功率进行评分（5分=全部成功，1分=全部失败）。这个分数会反馈给学习路由器，用于优化未来的模型选择，同时也用于任务预算追踪中的循环检测。
纠正提示：在执行工具调用前，系统会查询结构化的“经验教训”库，寻找与该工具及其参数匹配的已知陷阱。如果找到纠正建议（例如：“发送Telegram图片必须使用环境变量中的$TELEGRAM_BOT_TOKEN，切勿使用占位符”），则会将其作为系统消息注入到工具结果之后。这样，模型能在不打断工具调用消息链的情况下，获得纠正性上下文，避免重复犯错。
3. 成本控制机制：从全局预算到任务级熔断
3.1 任务级预算强制执行
除了全局的每日2美元预算，每个任务都有自己独立的预算，由一个“每任务追踪器”强制执行。这防止了单个失控任务耗尽全天预算。
| 任务复杂度 | 最大调用次数 | 最大成本 |
|---|---|---|
| simple（简单） | 3 | $0.10 |
| internal（内部） | 3 | $0.10 |
| classify（分类） | 3 | $0.10 |
| email（邮件） | 5 | $0.20 |
| format（格式化） | 5 | $0.20 |
| tool（工具） | 5 | $0.30 |
| search（搜索） | 5 | $0.30 |
| medium（中等） | 15 | $0.50 |
| hard（困难） | 20 | $1.00 |
当某个任务超出其调用次数或成本限制时，系统会立即阻止该任务的进一步API调用，并通过Telegram向人类操作员发送升级警报。此外，如果连续三个回合的评分都是1/5（所有工具调用失败），也会触发相同的封锁机制。这能捕获那些代理反复尝试同一失败方法的循环。任务追踪器每小时重置一次，防止陈旧状态阻塞合法工作。
3.2 渐进式降级状态机
系统通过检查行动日志中最近20个工具调用的结果，持续评估其运行健康状况。错误率阈值会触发渐进式的自治权降低：
| 降级等级 | 错误率 | 最大迭代次数 | 是否需要人工介入 |
|---|---|---|---|
| full（全功能） | < 30% | 20 | 否 |
| cautious（谨慎） | 30%-50% | 10 | 否 |
| supervised（受监督） | 50%-75% | 5 | 是 |
| paused（暂停） | > 75% | 0 | 是 |
降级状态会持久化到SQLite，即使服务重启也能保持。超过1小时的陈旧状态会自动重置为full，防止一次糟糕的会话永久性地降低系统能力。在supervised级别，工具权限会被限制为“仅代码”配置文件，阻止代理进行外部API调用、发送邮件或修改部署。在paused级别，代理会返回一条人类可读的错误信息，解释错误率并请求人工审查。
3.3 工具级断路器
单个工具也有自己的断路器，用于追踪连续失败次数。在3次连续失败后，断路器“打开”，该工具将被封锁5分钟。恢复超时后，断路器进入“半开”状态，允许一次探测调用。如果探测成功，断路器关闭；如果失败，则重新打开。此外，一个每30分钟运行一次的心跳系统会主动探测已知脆弱的工具（如Docker沙箱），并在它们恢复时重置断路器。
实操心得：“预算”和“降级”必须联动。我们最初的版本只做了全局预算检查，结果就是一个任务在预算内疯狂循环，直到触发降级。现在，预算消耗会直接影响路由（强制降级到更便宜的模型），而错误率会触发降级状态（减少迭代次数、限制工具），两者结合形成了一个多维度的防护网。
4. 本地模型脚手架：三次廉价尝试胜过一次昂贵调用
4.1 受ATLAS启发的生成-评分-修复流水线
对于许多生产任务类型，我们采用了一个核心策略：用本地模型的多次尝试，替代一次昂贵的云API调用。smart_local.py模块将本地Ollama模型包装在一个三阶段的质量流水线中，灵感来源于工具增强语言模型的ATLAS框架：
第一阶段：生成（Generate）为给定任务生成N个候选结果（默认为3个）。每个候选结果会收到不同的风格提示（如“直接简洁”、“富有创意”、“详尽细致”），以在不改变温度（Ollama API未提供细粒度温度控制）的情况下鼓励多样性。
第二阶段：评分（Score）每个候选结果都会根据任务特定标准进行自我评估。我们使用一个结构化提示，要求模型输出JSON，包含每个标准的分数（1-10）、总分以及识别出的问题。模块会优雅地处理解析失败：先尝试通过正则表达式提取JSON，回退到从文本中解析“N/10”模式，如果全部失败则默认给一个中性分数5。
第三阶段：修复（Repair）如果最佳候选的分数低于最低阈值（默认为6分），并且评分阶段识别出了具体问题，模型会获得一次修复机会。修复提示包含原始内容、识别出的问题以及质量标准，要求进行有针对性的重写。
关键洞察在于：对于许多生产任务类型，三次廉价的本地尝试，其综合效果优于一次昂贵的API调用。例如，一条由Qwen2.5-14B通过生成-评分-修复流水线生成的社交媒体帖子，API成本恰好为$0，其产出质量足以满足社交平台发布要求。而同样的任务如果路由到Sonnet，每次发布成本约为$0.03，仅每日社交内容一项，每月成本就接近$0.90，几乎占月预算（$60）的1.5%。
4.2 本地模型的任务路由
有八类任务默认路由到本地模型：simple（简单问答）、internal（内部通信）、note（笔记）、classify（分类）、summarise（摘要）、self-knowledge（自省）、email（邮件处理）、format（格式化）。选择这些类型的依据有两点：1) 本地模型能产出可接受的输出（生产质量评分平均2.9/5，在这些特定任务上与云模型相当）；2) 这些任务不需要工具调用，而Qwen2.5-14B在工具调用上并不可靠。
当云API对于纯文本任务（无工具调用要求）失败时，路由器会自动回退到本地模型，以零额外成本提供对API中断的弹性。
4.3 便捷函数封装
该模块提供了任务特定的包装函数，如smart_social_post()（支持平台感知，包含字符限制和平台特定标准）、smart_summary()（为效率减少了候选生成数量）和smart_draft()（通用草稿）。这些函数将关于质量标准的领域知识编码到流水线中，使得调用者无需每次指定标准即可使用。
5. 生产数据复盘：从日均13美元到1.5美元的蜕变之路
5.1 成本演进与关键事件
在18天的运营期（2026年3月23日至4月9日）内，系统处理了1,562次调用，总成本50.43美元。每日成本分布讲述了一个系统学习其约束的故事：
| 时期 | 天数 | 平均日成本 | 最高日成本 | 预算合规天数 |
|---|---|---|---|---|
| 第一周（3月23-29日） | 7 | $4.42 | $13.15 | 3/7 (43%) |
| 第二周（3月30日-4月5日） | 7 | $1.52 | $6.97 | 5/7 (71%) |
| 第三周（4月6-9日） | 4 | $1.46 | $4.31 | 2/4 (50%) |
“灾难日”分析（3月23日，$13.15）： 代理被要求设置一个新的集成。它遇到了一个API错误，重试，再次遇到，然后进入了一个循环：单日499次API调用，每次调用消耗约$0.03。当时无人值守。每日预算检查虽然存在，但只在任务开始时运行一次，而不是每次调用前都检查。等到操作员发现时，系统已经在一个失败任务上花掉了日预算的6.5倍。
这一天直接催生了三项架构变更：
- 每任务调用限制：防止单个任务消耗全部预算。
- 每次调用预算检查：而不仅仅是每次任务。
- 循环检测：连续三次1/5的质量评分将封锁任务并发送Telegram警报。
3月28日重演了类似模式（$12.33，340次调用），但每任务限制更快地捕获了它，只是当时的限制设置得过于宽松，后来被收紧。
到第二周，尽管工作量相同，平均日成本下降了66%。4月2日的$6.97日成本（182次调用）是由一次长时间的内容生成会话导致的。4月6日的$4.31日成本则暴露了一个更隐蔽的Bug：系统自身的成本控制文档已经过时。它基于过时的模型定价假设运行，因为CONTEXT.md（代理每次会话都会读取以理解自身规则的文件）在上次变更后没有更新。系统因为忘记了自己的规则而打破了自己的预算。这提醒我们，代理的“知识”必须与代码库保持同步，自动化更新CONTEXT.md应成为CI/CD流程的一部分。
5.2 模型使用与成本效率分析
| 模型 | 调用次数 | 总成本 | 平均每次调用成本 | 平均质量分 | 成功率 |
|---|---|---|---|---|---|
| Claude Sonnet 4 | 1,192 | $42.77 | $0.036 | 2.31/5 | 100% |
| GPT-4o | 247 | $7.46 | $0.030 | 2.56/5 | 98.8% |
| Local (Qwen2.5) | 101 | $0.00 | $0.000 | 2.88/5 | 100% |
| Trinity-Thinking | 10 | $0.02 | $0.002 | 3.60/5 | 100% |
| Claude 3.5 Haiku | 10 | $0.19 | $0.019 | 3.00/5 | 100% |
几点观察：
- 质量评分偏差：评分机制（1分=所有工具调用失败，5分=全部成功）导致分数呈两极分化。603个回合得1分，133个回合得5分，中间分数很少。这反映了工具执行的二元性（成功或失败），而非细致的质量评估。Sonnet平均分较低（2.31）可能反映了它被用于工具调用最多、部分失败更常见的困难任务。
- 本地模型验证：本地模型（Qwen2.5）在101次调用中保持了100%的成功率，但这些调用仅限于文本生成任务。其2.88的平均质量分与云模型相当，验证了将简单文本任务路由到本地的决策是正确的。
- 提示缓存价值：Sonnet的提示缓存估计在整个观察期内节省了约7.27美元。
5.3 每周成本趋势
| 周次 | 调用次数 | 总成本 |
|---|---|---|
| 第12周（3月23-29日） | 1,082 | $33.11 |
| 第13周（3月30日-4月5日） | 334 | $11.48 |
| 第14周（4月6-9日） | 146 | $5.84 |
从第12周到第14周，每周成本降低了82%。这反映了三方面因素：成本控制的成熟（每任务预算、循环检测）、引入Trinity作为预算层替代Haiku，以及改进的任务分类将更多工作路由到本地模型。系统确实从错误中学习了，无论是通过结构化的经验教训库，还是通过操作员驱动的规则更新。
6. 架构教训：不要构建重复代理功能的中间件
6.1 V1：中间人架构的陷阱
最初，我们为处理露营装备语音评论构建的流程，遵循了代理系统中一个常见的反模式：构建一个专门的子流程。
- 语音消息通过Telegram到达。
- 一个Python子进程调用OpenAI Whisper API进行转录。
- 另一个单独的GPT-4o-mini调用对转录文本进行分类（这是装备评论还是普通消息？）。
/tmp中的状态文件跟踪对话流。- 一个专用处理器处理提取的评论并将其保存到Notion。
这个架构拥有你能预料到的所有问题：
- Python子进程崩溃时静默失败。
- 没有对话上下文（分类模型不知道用户之前说过什么）。
- 装备评论检测的误报率高（任何提及产品都会触发评论流程）。
- WSL2网络中断导致Telegram文件下载静默失败。
/tmp中的状态文件在服务重启后无法存活。
Git提交历史通过提交信息讲述了这个故事：“修复：语音消息现在具有上下文感知”、“修复：仅当检测到产品/评分时才创建语音转录评论”、“修复：完全禁用用于评论检测的正则表达式回退”。每个修复都只解决了症状，而非根本原因。
6.2 V2：让代理自己处理
解决方案是停止构建重复代理现有能力的中间件。V2版本用本地运行的faster-whisper实例（GPU上运行large-v3模型，HTTP API在9876端口）替代了Whisper API。转录变得免费且快速。转录后的文本作为普通用户消息直接馈送到主代理中。
代理本身已经拥有对话历史、工具访问权限、Notion集成以及判断消息是装备评论还是普通问题的上下文。专门分类器被完全移除。状态文件被移除。独立的处理器被简化为仅包含Telegram文件下载（为了WSL2可靠性，从Node.js fetch切换到Python requests）和本地转录调用。一个提交替换了数百行代码：“修复：语音代理在后台运行 - 不阻塞Telegram轮询”。
6.3 核心教训
不要构建重复代理功能的中间人管道。如果你的代理拥有对话历史和工具访问权限，那么将原始文本输入给它，几乎总是比构建一个独立的分类和路由层更好。专用层能力更弱（无历史、无工具、无上下文）、更难调试（独立的日志、独立的状态）、也更脆弱（更多移动部件、更多故障模式）。
这个原则不仅限于语音处理。任何时候，当你 tempted 去构建一个在代理看到输入之前进行分类、路由或转换的预处理管道时，问问自己：代理本身能否处理原始输入？在大多数情况下，它可以，而且因为它拥有完整的上下文，它会做得更好。
7. 实战避坑：在WSL2上运行生产AI的每一个坑
在WSL2上运行生产代理引入了一类在裸金属或容器部署中不会出现的问题。鉴于WSL2日益成为常见的开发和部署目标，这些经验值得记录。
7.1 网络不可靠性
WSL2上的Node.jsfetch在与外部API建立连接时，会出现不可接受的连接中断率。具体的故障模式是：连接成功，部分数据到达，然后流挂起或重置，且没有触发错误事件。AbortSignal.timeout()API有所帮助，但无法解决所有情况。
务实解决方案：将网络密集型操作委托给Python的requests库，它能更可靠地处理WSL2的网络栈。Telegram文件下载从Node.jsfetch切换到一个Python辅助脚本（telegram_download.py），该脚本处理下载并返回JSON结果。下载可靠性立即得到改善。
7.2 启动时序问题
WSL2的网络栈在启动时并未就绪。Telegram轮询客户端在首次连接尝试时会失败，如果没有重试逻辑，服务将在没有Telegram连接的情况下启动。
修复方案：Telegram启动时增加10秒的初始延迟，随后进行10次连接重试，其中前3次失败静默记录（以避免正常启动期间的误报警噪音）。
7.3 消息队列
即使在启动修复之后，运行期间的瞬时网络中断也会导致Telegram发送失败。
解决方案：实现一个后台消息队列。发送失败的消息进入一个重试队列，每5秒处理一次，最多重试30次（约2.5分钟）后放弃该消息。
7.4 长期解决方案
计划迁移到Discord（在内部工单系统CORE-009中跟踪）以解决根本原因。Discord基于WebSocket的连接模型原生处理重连，消除了在WSL2上使Telegram脆弱的轮询-重试模式。
踩坑实录：不要假设网络是可靠的。特别是在WSL2或容器化环境中，必须为每一次网络调用实现超时、重试和退避逻辑。我们最初认为“偶尔失败重试就好”，但WSL2下的失败率之高，足以让系统在无人值守时完全停滞。将关键路径（如消息接收、文件下载）的可靠性提升到“生产级”，是让自主代理真正可用的前提。
8. 支撑机制：任务配置、经验库与提示工程
8.1 基于配置文件的轻量级任务配置
系统没有使用命名的持久化代理实例，而是采用了从YAML配置加载的作用域任务配置。每个配置定义：
- 允许的工具：此配置可以访问哪些工具（例如，
admin配置可以获得邮件和文件工具，但没有部署工具）。 - 模型层级：路由到哪个复杂度级别（控制成本）。
- 经验类别：从结构化存储中注入到系统提示中的经验类别。
- 系统提示补充：特定于配置的指令和行为规则。
十二个配置覆盖了系统的运营领域：代码、研究、内容、运维、管理、审核、财务、数据、销售、客户、产品、战略、采购。任务分类使用针对YAML配置中映射表的关键词匹配，多词关键词比单词得分更高，以优先匹配更具体的任务。
这种方法比持久化代理实例更便宜、更简单。配置是无状态的，配置本身受版本控制，生成一个具有不同配置的子代理仅仅意味着改变可用的工具和注入的经验。没有单独的进程，没有代理间通信协议，没有状态同步。
8.2 结构化的经验教训存储
经验教训存储在支持全文搜索的SQLite中，按领域分类（工具使用、架构、工作流、环境、安全等），用严重性标记，并通过发生次数追踪。系统提示加载器查询前10个相关经验，并将其注入到稳定前缀中（从而实现提示缓存）。
经验教训也会在工具调用时被查询：在执行工具之前，系统检查是否存在针对该工具及其参数组合的已知纠正措施。如果存在，它们会在工具结果之后作为系统消息注入，为模型的下一次迭代提供纠正性上下文。
这形成了一个反馈循环：错误产生经验，经验修改未来行为，发生次数追踪则记录该经验是否仍然相关或已被取代。
8.3 提示缓存的架构设计
如前所述，系统提示被拆分为两部分。这种拆分是提示缓存高命中率的关键。稳定前缀包含了绝大部分的令牌（身份、规则和文档加起来有几千个令牌），而动态后缀则小得多。通过将稳定的、不常变化的部分标记为可缓存，我们显著降低了每次调用的令牌成本。在设计你的代理系统时，花时间分析和拆分你的系统提示，识别出哪些部分是真正静态的，哪些是每次都需要变化的。这个简单的优化能带来巨大的成本效益。
9. 总结与核心洞见
经过18天、1,562次调用、50.43美元总成本的生产运行，我们验证了“成本优先代理架构”的可行性。关键成果包括：成功将日均成本从第一周的4.42美元降至第三周的1.46美元，逼近2美元目标；6.5%的调用由零成本的本地模型处理且无质量损失；通过提示缓存节省了约14.4%的总成本。
然而，比这些数字更重要的是我们获得的核心洞见：
- 成本作为设计约束驱动质量：将成本视为首要约束，迫使你做出更明确、更健壮的架构决策。你不再盲目使用最强大的模型，而是必须根据任务价值精确匹配资源，这自然催生了分层、降级和回退机制，这些正是生产系统弹性的基石。
- 本地模型是“成本护城河”：对于大量无需复杂工具调用的文本处理任务（分类、摘要、格式化、草稿生成），现代开源模型（如14B参数的Qwen2.5）已具备生产可用性。通过“生成-评分-修复”等脚手架技术，可以进一步提升其输出可靠性，构建一道坚实的零成本防线。
- 监控必须与控制联动：仅仅监控成本是不够的。预算超支必须能实时触发路由降级、迭代限制甚至任务中断。错误率上升必须能触发自治权降低。监控指标必须直接反馈到系统的运行时决策逻辑中。
- 复杂性应留在核心代理，而非中间件：避免构建重复代理功能的预处理或后处理管道。这增加了脆弱性，却很少带来价值。尽可能将原始输入馈送给拥有完整上下文和工具访问权限的代理。
- 生产就绪在于处理故障，而非避免故障：在WSL2上遇到的网络问题、API的瞬时失败、模型输出的不可预测性，这些都是生产环境的常态。系统的健壮性不在于假设一切顺利，而在于当故障发生时，有明确的降级路径、重试机制和人工升级通道。
最后一点个人体会：构建一个在严格预算下运行的自主代理，就像训练一个精打细算的助手。你教会它的不是“不惜一切代价完成任务”，而是“用最合适的资源，聪明地完成任务”。这种“资源意识”本身，就是一种更高阶的智能。当你的AI开始关心电费和API账单时，它才真正开始为你工作，而不是相反。
