去年三月份我给自己定了一个在外人看来有点疯的目标一个人用九个月时间造一款真正能稳定服务真实用户的Harness架构应用。现在回头看那段日子我写下了将近20万行代码也让API账单达到了每个月烧掉40亿token的规模。很多人听到Harness架构第一反应是这不是软件测试里的老概念吗对Test Harness是个经典名词但到了AI应用领域它被赋予了完全不同的含义——给大模型套一套完整的工程控制框架。这篇文章不打算炫耀代码量在AI时代行数本身没什么意义我想认真拆解的是一个人从零搭建Harness架构应用、把它推到规模化运行到底要经历哪些关键决策、要付哪些学费。如果你也是独立开发者正在做AI Agent类产品或者正为居高不下的token消耗发愁这篇东西应该能帮你省掉不少试错成本。1. 我为什么非要自己造一套Harness1.1 裸调API跑Demo没问题一进业务场景就全乱一开始我和大部分人的做法一样写个函数把prompt丢给大模型拿回文本完事。这是最快的demo路径效果还很惊艳。但真实业务不讲武德——用户任务往往是查数据、判断意图、制定计划、调用工具、生成报告这样五步以上的行动链条。我自己第一次遇到这个难题时尝试的是最朴素的代码def handle_task(task): prompt build_prompt(task) response call_llm(prompt) return parse_response(response)单任务、单步骤时这段代码很清爽。可任务一旦拉长我就被迫在每一步把历史对话、工具说明、中间结果全部重新组装一遍。于是各种全局变量开始膨胀重复上下文越塞越多bug也以几何级数增长。模型那边经常失忆今天能复现的问题明天换个会话就复现不出来。这个阶段让我彻底明白模型本身不差差的是运行环境。模型需要一套稳定的工作台让它知道现在在做什么任务、已经做到哪、哪些信息可信、动作边界在哪。这就是我理解的Harness——一个围绕模型的工程控制层而不只是把prompt拼得更漂亮的技巧。1.2 Harness架构应用的五个核心零件我自己这套Harness最终沉淀成五块互相咬合的组件缺一不可模型网关Model Gateway统一管理模型路由、鉴权、限流和重试。业务代码不直接调模型全部走网关由网关根据任务复杂度决定该用哪款模型。上下文管理器Context Manager决定每次请求带哪些信息、不带哪些信息。它是整个系统里对token成本影响最大的模块后面专门展开讲。工具注册中心Tool Registry把业务能力包装成模型可调用的工具。统一Schema、统一参数校验、统一权限控制避免模型胡调接口。状态机与检查点State Machine Checkpoint记录每个任务走到哪一步了、做过哪些动作任务崩溃后能从检查点恢复而不是从头再来。可观测与审计Observability记录每次调用的输入输出、耗时、token消耗、费用估算。没有这一层Agent类应用后期基本没法维护。这套设计和市面上的AI编排框架有重叠但侧重点不同。编排框架主要解决怎么让模型做多步任务而Harness架构更强调怎么让这套系统长期可控、可恢复、可计费。所以哪怕我自己也参考过成熟框架最后还是决定核心自己写——独立开发者的处境是出了问题没人帮你背锅你只能靠对每一行代码的掌控力。1.3 自造Harness是自讨苦吃吗如果你只是要一个每周跑一次的小脚本那确实完全没必要造Harness半小时搞定反而体面。可如果目标是长期运行、多工具协作、状态复杂的AI应用Harness架构几乎是绕不开的选择区别只是你用现成框架还是自己写一套。我用一个赛车比喻解释给朋友听过模型是车手Harness是维修站团队。车手再快长途比赛中也不可能自己完成换胎、加油、策略调整。维修站的专业程度往往比车手天赋更决定最终成绩。AI应用也一样模型的单次表现像车手瞬间的爆发力而上下文管理、状态恢复、工具调度这些工程能力才是让你跑完一整场业务比赛的保障。所以不是要不要造Harness的问题而是你的Harness能不能接住业务复杂度的问题。2. 九个月20万行代码一次真实的增长拆解2.1 第1到第2个月用最脏的代码验证核心循环我不信先画三个月架构图再动手那套玩法。AI应用最大的风险是核心假设不成立不是抽象不优雅。所以我前两个月写的是彻头彻尾的脏代码工具逻辑直接硬编码在if/else里prompt模板全堆在一个大文件里历史记录拿字符串拼接没有任何框架可言。到第二个月结束时代码量大约1.5万行。这时候每次任务平均要烧掉10万token以上效率低得惊人——因为系统提示词写得很长所有工具描述全量塞给模型历史对话一条不删。但我完全不焦虑因为这一阶段赌的不是成本而是模型→工具→回到模型→继续执行这个循环能不能在真实数据上闭环。好消息是它闭环了坏消息是效率惨不忍睹。可没有这一步后面所有架构工作无从谈起。2.2 第3到第5个月Harness核心框架的重建期数据验证通关后我动真格开始重建。这三个月代码量从1.5万涨到接近8万是九个月里增长最快的阶段。优先做的前三件事是把任务协议定义成可序列化对象包含目标、上下文、当前步骤、历史动作、输出约束把上下文管理器单独拆出来停止无脑全量发送给每个任务接入状态机任务进度实时落库。第二个动作是这三个月里价值最大的它让我第一次有了为token花钱的掌控感。这期间也踩过坑。我一度把工具、上下文、策略抽象成三层接口做了大量以防万一以后要用的设计。结果真正高频使用的只有两层第三层纯属自我感动后来还增加了理解成本。教训很直白重构要面向真实问题不要为了架构美感提前抽象。2.3 第6到第8个月工具生态铺开代码量最陡的爬坡从第六个月开始应用开始服务真实用户各种工具和业务模块迎来爆发期。代码量从8万一路涨到15到16万。好多朋友以为这个阶段写的都是模型魔法代码实际情况恰好相反真正的代码大头是这些模块代码量约主要工作工具与业务接口3.5万行工具Schema定义、字段说明、第三方接口对接规则与校验逻辑4万行权限控制、参数校验、异常分支处理测试与Mock数据5万行回归测试、模拟数据、故障场景构造Harness核心框架4万行上下文管理、状态机、模型网关、可观测配置、UI与运维3.5万行管理后台、监控面板、部署脚本、日志分析真正和模型直接交互的代码可能只占两成。这是我觉得很多独立开发者容易低估的地方AI应用70%以上的复杂度不在模型对话上而在模型以外的现实世界——数据对不对、权限够不够、第三方接口挂没挂、失败怎么兜底。同时这三个月我加了输出强制校验层模型先输出结构化结果解析失败或校验不通过就把它自己的错误信息重新丢回去让它修正。这套机制显著提升了成功率代价是token又涨了一截但权衡下来非常值。2.4 第9个月冻结新功能专注稳定化最后一个月我强行冻结一切新需求只做三件事故障注入测试随机杀进程、断网络、塞超长上下文看系统怎么死、token用量熔断单个任务预算超限自动降级、以及把文档和设计记录补齐。最终全仓代码量稳定在20万行左右含测试。我坚持认为20万行对这个体量的应用不算膨胀。它不是一个模型应用壳而是几十种工具、十几个工作流、多层校验、完整测试与监控体系的合集。代码量增长主要来自业务宽度不是代码冗余。唯一要警惕的是大量重复的样板代码——我后期就删了大概1万行当时写着爽但后来没用的东西删完系统反而更稳了。2.5 代码量在AI时代到底说明什么说实话20万行代码放在传统软件项目里不算什么大数字放在AI应用里也并不会自动等于厉害。它真正说明的只有一件事这个应用的确不是demo而是一个被业务复杂度和工程细节填满的长期工程。代码量可以拿来衡量项目成熟度但千万别拿它衡量个人能力。真正有价值的是这些代码背后踩过的坑和做过的取舍。3. 每个月40亿token是怎么烧出来的以及我如何止血3.1 先算一笔账40亿token/月到底什么概念40亿token除以30天大约每天1.3亿token。如果平均每个任务烧5万token就是每天2600个任务。如果每个任务平均要跑20步Agent循环那每一步平均还不到6500 token。所以这个数字乍看吓人放在高频、多工具、长上下文的任务系统里其实是正常体量。这里有个很关键的认知LLM计费的大头永远是输入不是输出。我的系统里输入token占比长期在90%以上。更讽刺的是其中一半以上是重复发送的固定内容——同一个system prompt、同一批工具Schema、同一段历史记录每次调用都要原样发给模型一遍。换句话说每花1块钱有四五毛是在支付把已经发过的东西再发一遍的运费。3.2 不记录token的优化全是玄学第三个月开始我在Harness的可观测模块里加了步骤级token明细每次调用落一条记录包括任务ID、模型名、输入输出token数、缓存命中情况、预估费用。每天跑一个汇总报告按工作流、按工具、按用户排序一眼就能看出谁在烧大钱。这一点我必须强调如果你不做token记录你看到账单只会觉得模型真贵但你根本不知道浪费在哪。很多所谓贵其实是上下文重复发送、工具张数冗余、任务路由不够科学的锅模型本身冤枉得很。先有数据再谈优化这是所有成本治理的地基。3.3 真正把账单打下来的四个手段在业务量持续上涨的前提下token总量从峰值月40亿左右降到20到25亿成本接近腰斩。按输入每百万token约2.5美元、输出每百万约10美元粗算优化前月成本大概1.2万到1.5万美元优化后大概5千到6千美元。有效手段按见效速度排Prompt缓存把稳定的system prompt、工具Schema、历史摘要整体做成可缓存的固定前缀。命中缓存的输入部分费用大幅下降这一步直接砍掉约35%成本。上下文压缩并选择性携带给每个任务定token预算超额就把早期对话摘要化。关键字段用户ID、任务目标、最终约束保留原文其余历史转成压缩摘要。模型分级路由能轻则轻。信息抽取、简单分类交给轻量模型复杂推理和代码生成再切重型模型。核心是一个小小的复杂估计算子性价比高到离谱。工具Schema动态裁剪把几十个工具的完整描述全部塞给模型是巨大浪费。我改成按任务动态装配候选工具集每次只带5到8个工具的Schema输出质量没掉输入成本却少了一大截。放一段上下文管理器最朴素的逻辑骨架不是某个具体框架的实现只是Harness里一个概念示意class ContextManager: def __init__(self, token_budget: int): self.token_budget token_budget self.system_prefix # 稳定不变的system prompt self.history [] # 动态历史记录 def build_messages(self): return [self.system_prefix] self.compress(self.history) def compress(self, history): # 预算充足就原样携带超了就做摘要压缩 if estimate_tokens(history) self.token_budget: return history # 关键字段原样保留其余历史转成摘要 return [summarize_turn(h) for h in history]真实版本比这复杂得多缓存key怎么构造、摘要触发策略、压缩后和原文一致性怎么校验全是细节。但核心思想一句话别让模型为它根本用不到的信息付费。3.4 token消耗的真正信号价值指标优化前月峰值优化后月均token总量40亿20到25亿成本估算约1.2万到1.5万美元约5千到6千美元缓存命中率很低较高平均任务token5万左右3万左右任务成功率95%左右99%以上到了后期我干脆把token当成应用架构效率的度量单位。如果一个任务的token特别高优先怀疑的不是模型贵而是上下文有没有被重复发送、工具集有没有裁掉、路由有没有分级。把系统调优后token会自然回落。它不是某个需要咬牙切齿省的开支而是暴露架构问题的早期报警器。4. 单兵作战九个月我最想留下来的三条教训4.1 没有检查点的Agent任务脆弱得让人后怕有一阵我图省事线下看起来跑得稳定线上就少写了点状态恢复逻辑。结果线上一次任务跑到第12步时进程被OOM杀掉任务没有检查点只能整体重跑。用户干等了一个多小时最后等到的还是一场失败。第二天我把状态机落库排到最高优先级所有任务全部改成事件序列每步结束自动写检查点重启后先校验上下文完整性缺失就补。这个改动让任务成功率从95%干到99%以上。模型会出错、进程会挂、API会超时这些都是常态不是意外。对Agent类项目来说状态恢复能力不是锦上添花是生存底线。4.2 可观测性不是可选项一个人的记忆力完全不可靠独立开发者最大的敌人不是写不出代码而是三个月后回头看自己代码时的失忆。我坚持从项目之初就记录一切模型的每次输入输出、工具调用结果、token明细全部落日志。到了后期线上Agent出问题基本全靠trace日志排查——按任务ID拉出完整链路看模型在哪一步理解偏了、工具在哪一步返回了脏数据、上下文在哪一步被压缩过度。如果你一个人做AI应用请从第一天就搭好最小可观测体系结构化日志强制带任务ID和步骤ID配一个能按ID检索的服务就够用。别指望记忆在Agent的复杂链路里记忆是完全不可靠的。4.3 别等架构完美再动手头两个月的脏代码才是整段经历的宝藏如果一个人从第一天就追求完美Harness架构大概率第三个月还在写框架因为需求没验证、坑没踩过、抽象全凭想象。我用前两个月的脏代码换到了对真实业务的理解之后动手重写时我才分得清哪些地基是必选项、哪些抽象是自嗨。如果你想做独立AI应用我的顺序建议永远是先用最脏的方式让核心循环跑通再基于事实做架构化。先跑通、再重构这个顺序不要反过来。4.4 给准备单兵作战的AI开发者几条实用清单带着现在的认知回到项目开始之前我会把下面几条贴在显示器边框上项目前两周就把版本管理、CI和基础测试体系配好。后面再补的代价是前两个月的每一次改动都要担心改坏了谁。每天睡前看当日token消耗第二天早上第一件事查异常任务。日拱一卒式的监控比月底看账单扎心强一万倍。任务级状态落库从第一天做不要等项目变大了再补。状态恢复能力越早拥有后面省的事越多。敢于删代码。我删掉的那一万行没有任何遗憾它们的消失让系统更容易被理解。从架构上默认失败会发生而不是默认成功。Agent每一步都可能出错你的Harness一旦建立在不会失败的假设上就一定会被现实打脸。5. 收尾之前聊聊我对模型边界和工程控制的最新体会九个月写了20万行代码对我改变最大的其实不是技术细节而是对模型能力边界的认知。模型再聪明也得有人给它布置跑道、设好护栏、修好故障后的应急通道。Harness架构做得好不好直接决定一款AI应用的上限有多高、账单下限有多低。那些真正跑得又稳又省的系统往往不是靠某个神级Agent提示词而是靠一套不显眼的工程底座把模型每一次输出的不确定性都控制在可接受范围里。这个项目现在还在持续迭代我手里的方向是进一步降低推理延迟、让工具Schema的生成更自动化以及探索更聪明的轻量模型路由策略。以后有新沉淀我再来更新。如果你也在做类似的事欢迎聊一聊你自己是怎么管理token预算的——这个问题的答案往往能看出一个AI应用的真实工程水平。