“Agent in a Bottle”这个标题第一次看到我就乐了。这不就是把“瓶中精灵”的梗搬到了大模型智能体身上吗——你召唤一个Agent它呼风唤雨帮你解决复杂问题然后……就没有然后了。能力随着会话结束一起消散下一次遇到同类问题又得重新召唤、重新推理、重新烧一遍token。真正让我停下来认真思考的是后半句“Can LLM Agents Turn Their Capabilities into Cheap Artifacts?”这里的“Cheap Artifacts”才是整句话的灵魂——Agent能不能把自身那种昂贵、随机、不可控的推理能力沉淀成一种廉价的、可复用的、像文件一样的“制品”如果能这件事的价值可能比Agent本身还大。我这段时间一直在折腾这个方向踩了不少坑也有了一些拿得出手的成果。今天就把我对这个问题的理解、尝试过的方法、以及一套亲测可行的封装思路完整写出来。这篇东西适合两类人一类是正在做Agent应用、被成本和稳定性反复折磨的开发者另一类是天天听“Agent能力很强”但不知道该怎么把它变成实际资产的业务方。不管你是哪一类读完之后你至少能带走一个可以直接上手的“能力固化”框架。1. 先拆题目Agent的能力凭什么能“装进瓶子”1.1 什么是Agent的“能力”一个LLM Agent在解决实际问题的过程中到底在运行什么拆开来看无非是这几样东西规划能力把一个大目标拆解成一系列子步骤决定先做什么、后做什么、什么可以并行。工具调用能力知道什么时候该去查数据库、什么时候该调API、什么时候该检索文档。推理与判断能力在拿到中间结果后判断当前状态是否符合预期决定继续执行还是调整策略。记忆与上下文组织能力在大段对话历史中保持目标感不跑偏不丢失关键约束。这些能力在Agent运行的时候每一样都在消耗真金白银。每多一次推理就多一轮token消耗每多一轮工具调用就多一次延迟每多一次状态判断就多一分不确定性。我见过一个实际任务Agent花了二十多轮才把一份杂乱的数据清洗干净光是中间推理就烧掉了好几万token结果用户只是想要一个“下次能直接跑”的清洗脚本。这就是问题的根源Agent的能力以“过程”的形式存在而不是以“结果”的形式存在。过程是昂贵的、不可复制的、每次都得重演的。而我们要做的恰恰是把过程压缩成结果——把一个动态的高消耗过程变成一个静态的、可以用极低成本反复调用的“东西”。1.2 什么才算“制品”“Artifact”这个词在传统软件工程里指构建过程的产物——编译出来的二进制、打包好的镜像、生成的文档。放到Agent的语境下我理解的“制品”是这样的它是一个可独立保存的实体不依赖某一次对话上下文、不依赖特定的会话ID。它承载了Agent在某一次运行中积累的关键决策模式而不是随机聊天的文本片段。它的调用成本远低于重新运行一个Agent可以看作“能力的一次性投入摊销到无数次廉价使用”。打个比方Agent是那个炼丹的炉子而制品是最后炼出来的那粒丹。炉子每次起火都费钱费时但丹炼成之后你随时可以拿出来用不用再起火。从这个标准出发提示词模板勉强算半个制品因为它是可复用的但没有固化Agent的完整行为模式一段固化下来的代码算制品但丢失了Agent的理解能力一套配置化的工作流算制品但灵活性不够。真正意义的“Agent能力制品”是那种拿走就能用、用起来感觉不到Agent存在、但效果比普通脚本聪明得多的东西。1.3 为什么现在讨论这个问题特别合适现在的Agent应用普遍卡在一个尴尬位置单次效果惊艳规模化就露馅。原因很简单——每次都让Agent从头开始全面推理成本经受不起稳定性经受不起响应速度也经受不起。我接触过很多团队他们做Agent验证期特别兴奋但一到要考虑真实成本和用户体验的阶段就会发现自己根本不敢让Agent自由发挥。现在这个问题已经被推到台面上大家都在找一条路能不能让Agent只在“生产知识”的时候出场之后就让这些知识自己去解决大多数问题我觉得现在正是认真回答这个问题的时候。2. 从“每次都重跑推理”到“拿现成工件”成本逻辑的全新叙事2.1 算一笔明账Agent跑一次到底贵在哪很多人对Agent的“贵”只有一个模糊的概念我拿一个常见的业务场景来算笔账。假设Agent要完成的任务是“根据客户提供的需求文档生成一份技术方案初稿”输入一份3000字的文档差不多4000 token。规划阶段Agent要先理解需求、拆解结构、确定方案章节这一层推理大概要消耗2000~3000 token。执行阶段它可能要先检索内部知识库3~5次检索中间夹杂推理判断再分段生成方案内容每段都要带着上下文重新推理各段累计可能消耗8000~12000 token。反思修正写完之后Agent可能还会自查一遍又烧掉2000~3000 token。合计下来完成这一单大概要消耗2万token左右。按主流大模型的API价格折算成本是几块钱看起来不多对吧但注意这只是一次任务。如果你的业务每天有1000个这样的需求进来那就是几千块一天一年上百万。而且这还没算延迟——一次完整执行往往需要几十秒甚至几分钟用户可没耐心等。再看另一种做法如果这个Agent已经被“封装”成了制品同样的输入进来系统只需要把客户文档丢进一个预设好的结构化流程调用一次针对性较强的模型推理按模板填充生成总消耗可能控制在3000 token以内成本缩到原来的六分之一延迟缩短到原来的十分之一。2.2 制品为什么能便宜这么多要理解这个成本差距关键在于想明白一个问题Agent在“规划”的时候到底在干什么当Agent面对一个新问题时它其实在做一种“高不确定性的探索”——它不知道最佳路径是什么只能根据经验临时推导甚至要试错。这个探索过程是最烧token的也是最容易出错的。但如果你已经在之前无数次运行中把最佳路径摸清楚了并且把它写成了一个制品的骨架那Agent再跑的时候就不需要探索了它只需要做“确定性执行”。这就好比导航。第一次去一个陌生的目的地你需要开着导航反复调整路线耗油费时。第二次、第三次去同一个地方你还每次都要重新规划一遍吗正常人会直接记住那条最优路线。Agent制品的本质就是把“记住的最优路线”保存下来省掉每次重新规划的油钱。还有一个常被忽略的点推理次数越少错误率越低。Agent每次自由发挥都是一次潜在的出错机会——规划偏了、工具调错了、判断失误了、输出格式不对了。把能力封装成确定性更高的制品后出错的概率也会大幅下降这省下的不只是钱还有人工排查问题的精力。2.3 用制品重新定义Agent的商业模式一旦把Agent的能力变成可以单独定价、分发、复用的制品整个价值逻辑就变了。以前你做Agent应用价值体现在“我给你跑一个任务你付一次钱”这本质上是在售卖算力和推理过程。但如果你能做出一批优质制品——一个能自动生成某类报表的制品、一个能处理某类客服问题的制品、一个能辅助代码审查的制品——它们就可以像软件一样被售卖、订阅、组合。买家不需要知道背后有Agent只需要知道这个东西能替他解决问题。我甚至觉得将来真正值钱的不是某个大模型也不是某一个Agent应用而是海量经过验证的“能力制品库”。这个库里的每一个制品都是某类问题的最优解固化体价格低廉、效果可靠。这才是标题里“Cheap Artifacts”真正的商业含义。3. 把能力装进瓶子的四种主流封装路线3.1 路线一提示词固化——最轻量但最不稳做法很简单从Agent的成功运行轨迹中提炼出它的思考模式、决策规则和执行顺序把它压缩成一份结构化的提示词模板。下次同类任务进来不走完整的Agent流程直接用这份模板加少量上下文单次调用模型输出结果不循环推理、不反复调工具。优点很突出实现成本极低几分钟就能把一次对话里Agent的思路变成模板调用成本极低一次大模型调用就出结果。缺点也同样明显提示词再长也有极限没法承载复杂的决策逻辑模型对提示词的理解经常波动同一个模板换了输入输出质量可能有明显起伏——你把十次对话压缩成一段话损失掉的正是Agent在整个过程中反复修正的那些微妙判断。我的经验提示词固化适合那些“单次推理就能完成”的能力比如内容分类、关键信息抽取、风格改写这类任务。只要Agent原来的完成路径本身就不复杂用提示词封装就够用。适合结构复杂的任务勉强压缩进去只会牺牲稳定性。3.2 路线二工具封装——把“会想”变成“能用”工具调用本身就是Agent能力的天然封装点。当一个Agent在解决问题的过程中发现“这件事我以后还会反复做”就可以把当前这一步固化成一个小工具——函数、脚本、API都行——以后其他进程直接调用这个工具不需要再让Agent重新理解这一步。举个例子。我做过一个数据诊断Agent它最初的流程是读数据文件 → 发现字段类型异常 → 调用模型推理原因 → 给出修复建议。运行多了之后我发现“发现字段类型异常”这个环节的判断规则其实越来越稳定完全可以写成一个独立的检测函数。于是我把它从Agent流程里摘出来做成了一个工具函数几个关键代码就能完成原来需要模型推理才能完成的事。工具封装的精髓在于用代码固化那些已经被Agent反复验证过的判断逻辑。这些逻辑最初由模型“顿悟”出来但一旦稳定就不再需要模型了。这就是把一个“能力点”变成一个“制品点”。3.3 路线三工作流编排——单体Agent的替身路线二解决的是单点能力固化路线三解决的是整体流程固化。如果把Agent的一次完整运行拍成一部电影工作流就是这部电影的分镜脚本什么时候取数据什么时候做判断什么时候调模型什么时候生成结果全部编排成确定性的步骤。和提示词固化的区别在于工作流是“多步骤的编排结构”每个步骤内部可以是模板、代码、或者小型的模型调用但步骤之间的顺序是固定的——不需要Agent每一步都自己决定下一步干什么。这条路线我目前用得最多。它的好处是既能保留Agent智慧的“胶囊化”效果又能用工程手段保证可靠性和可观测性。其中一个核心技术是把Agent运行轨迹里的决策点识别出来如果在实际运行中某个决策点Agent每次都用同一个策略解决那这个点就可以在工作流里固定下来只有那些Agent确实会根据情况灵活变化的点才保留模型推理的余地。工作流编排之后整个执行就变成了输入进来 → 按固化好的顺序执行 → 在保留下来的少数决策点调用模型推理 → 输出结果。从外面看它还是那个能解决问题的系统但里面已经从“全程自由发挥”变成了“关键节点智能判断”。3.4 路线四知识蒸馏——把推理轨迹变成可查询的资产这是四种路线中最接近“膏丹”的那一种。它的起点是记录Agent每次运行的完整轨迹包括它的每一步推理、每一次工具调用、每一个中间判断。然后对大量轨迹做结构化和提炼最终把有价值的部分组织成一个可以被直接检索和引用的知识库或规则集。这个思路的核心变化是Agent不再负责实时推理而是负责提前生产知识。Agent花大成本研究出的结论、总结出的规律、验证过的方法沉淀下来后普通系统可以通过检索直接使用。比如一个安全分析Agent对某类攻击模式做过深度分析那这些分析结论就可以被蒸馏成检索式的知识条目后续分析同类事件时检索直接命中不再需要Agent重新推理一遍。知识蒸馏的缺点也很实在耗时耗力需要梳理大量轨迹而且见效慢。但它有一个独特优势——积累性。其他的封装路线是“把一次成功复制无数次”而知识蒸馏是“让经验的雪球越滚越大”。长期来看这可能是最值得投入的路线。下面这张表是我在做方案选型时自己整理的直接放出来供参考封装路线固化对象实现成本调用成本稳定性适用场景提示词固化单轮推理模式极低极低一般分类、抽取、改写工具封装单点判断逻辑低极低高诊断、转换、计算工作流编排整体执行流程中中高多步骤业务处理知识蒸馏推理轨迹经验高极低极高分析决策类任务4. 实操演示把一个Agent的调研能力封装成可复用制品4.1 选定一个适合练手的场景理论讲再多不如自己动手装一次瓶子。我选一个特别典型的场景竞品调研Agent——给它一个产品关键词它自己去搜索信息、梳理维度、生成调研报告。这个场景适合做封装是因为它的问题足够典型Agent有大量重复性操作搜索、筛选、归类、总结有明确的输出结构报告而且每次调用都烧不少token——所有痛点集齐了。做封装之前我先跑了一遍原始Agent记录了完整的运行轨迹大致结构是对关键词做上下文理解生成调研计划搜索词变体、信息来源范围、报告章节。执行多轮搜索平均6~8次检索。对每次结果做相关性判断过滤无效信息。对有效信息按产品特性、市场表现、用户评价、竞品动态等维度拆解归类。基于归类信息生成结构化报告做最后的事实核查。跑完一次token消耗大概在1万8左右耗时3分多钟。这个过程就是我接下来要做成“制品”的原始素材。4.2 第一步把Agent的运行轨迹拆成“可固化”和“需保留”两类这一步是整个封装的核心难点。我拿了一张纸把Agent跑的每一步都列出来然后逐一问自己一个问题这一步是在执行一种已经确定的规则还是在做一种需要临时判断的高智慧行为比如“把搜索结果的标题和摘要按产品特性、市场表现等维度归类”——这一步Agent每次都按同一套标准来规则非常稳定那它就可以固化成一段分类代码或者一份映射规则表。但“判断这条搜索结果是不是当前竞品的新动态”——这一步很微妙同样的关键词在不同时间搜出来的结果质量差异很大需要Agent根据语义灵活判断这个就不能强行固定否则容易误判。我的建议是第一次做拆解时不要贪心。哪怕你只能从Agent的完整流程里固化出30%的步骤也值得做。每一次从Agent包袱里卸下一个固定步骤制品的成本和不确定性就双重下降这个是正向激励。我第一版制品只固化了“信息归类”和“报告框架”两步但已经明显感觉到差别了。4.3 第二步设计制品结构——用一个伪代码来描述我自己在设计Agent制品时习惯先用伪代码把整个结构画出来确认逻辑通顺了再写实际配置。上面这个调研Agent的制品结构是这样的输入产品关键词 1. 调用一次分类模型将关键词拆解为3-5个搜索子主题保留模型推理因为每个产品搜法不同 2. 按固定子主题清单生成搜索URL组合完全固化纯字符串模板 3. 并行执行固定次数的信息抓取完全固化固定检索范围 4. 对抓取结果做一次相关性过滤保留模型推理因为信息质量是动态的 5. 对过滤后的信息按固定维度填充到报告模板完全固化纯字典映射逻辑 6. 调用一次生成模型根据填充好的维度内容生成通顺报告段落保留模型推理因为语言表达需要灵活 输出报告草稿你可以看到我把原来的完整Agent流程拆成了一个“复合材料结构”——确定性步骤用代码和模板包住只有6个环节里面真正需要智慧判断的3个环节才留给模型推理。这样整体结构就是一个可以复用的“制品”而不是一次性的Agent对话。4.4 第三步固化实现——以工作流编排为例落地把伪代码变成一个可以运行的东西我这里的做法是把它落地成一套“脚本 配置”的工作流。核心代码结构是这样的代码做了简化保留关键逻辑# -*- coding: utf-8 -*- # 竞品调研Agent制品 - 工作流示例 # 结构固定步骤 关键决策点 def run_brief_artifact(product_keyword: str) - dict: # 第1步调用一次模型拆解搜索子主题关键决策点 sub_topics llm_call( system你是竞品调研助手只输出JSON列表将产品关键词拆成5个搜索子主题。, userf关键词{product_keyword}, max_tokens300 ) # 第2步固定模板生成检索组合纯代码逻辑 search_queries build_search_urls(sub_topics, fixed_dimensions[产品特性, 用户评价, 市场表现]) # 第3步固定抓取伪代码 raw_results fetch_results(search_queries, max_items40) # 第4步相关性过滤关键决策点 filtered llm_call( system你是信息筛选器判断每条结果是否包含与目标产品相关的有效信息输出保留或丢弃。, userformat_results_for_judge(raw_results), max_tokens800 ) # 第5步按固定维度填充报告框架纯代码逻辑 report_blocks fill_report_template(filtered, dimensions[产品特性, 用户评价, 市场表现]) # 第6步生成通顺段落关键决策点 final_report llm_call( system你是一位市场分析师根据填充好的素材为每个维度生成一段专业通顺的分析。, userformat_blocks_for_generation(report_blocks), max_tokens1500 ) return {report: final_report, token_cost: estimate_tokens()}这个结构有几个明显的优点每一步都是可见的、可测试的。我不用再像调试Agent那样靠日志去推测它到底在干嘛每一步的输入输出都是确定的。决策点集中且数量少。模型推理被收敛在三个环节每个环节的任务描述都极其聚焦输出格式也被严格约束成了JSON或者固定结构出错概率大幅下降。可以按步骤升级。如果我觉得“相关性过滤”这个决策点现在用模型判断太贵了我可以把历史数据积累起来训练一个小的分类器来替代它制品会越做越便宜。4.5 第四步测定封装前后的价格与质量差异封装完之后我用同一批测试关键词跑了对比测试每组5个关键词取平均值。结果如下指标原始完整Agent封装后制品变化平均token消耗185003100降低83%平均耗时约3分20秒约40秒降低80%报告完整性4/5分4.2/5分略升可控失败率约15%约3%降低12个百分点让我比较意外的是报告质量没有因为封装而下降反而略升了一点。原因也不难理解——原始Agent虽然自由但偶尔会在途中跑偏去关注一些不重要的信息封装后的制品把信息归类范围严格锁死在与竞品调研最相关的维度上反而不会跑偏了。当然这是单次测试的结果样本量有限但这个趋势确实符合我的判断很多问题是因为放权太多导致的而不是因为能力不够。5. 从做封装实验到落地实践中最值得你避开的几个坑5.1 坑一过度封装把所有灵活性都消灭了我最早做的几个制品里犯过一个典型的错误——把Agent的所有环节都强行固化连相关性判断这种高度依赖动态信息的环节也用一个固定规则来处理结果产品数据稍一变化制品的输出就出现明显错误。原因很简单固定规则是静态的而现实世界的信息是动态的。封装的目标是消灭“不必要的推理”而不是消灭“必要的推理”。我在实际操作中总结出两条判断标准如果某个环节的输入模式非常稳定比如永远固定格式、固定来源放心固化。如果某个环节的输入内容差异很大、质量参差不齐不要急着固化先让模型跑着之后积累了足够的判断样本再逐步压缩。这一点要牢记每次都全自动迟早会翻车关键位置保留一点“人味”反而更稳。5.2 坑二固化的时候只复制了表象丢了深层逻辑还有一种更隐蔽的失败你确实把Agent的步骤按顺序写成了代码但复制过来的只是表面动作——比如Agent每次都要调用某套检索逻辑你固化了检索逻辑却没固化“为什么要检索这些内容”的判断逻辑。下一次遇到一个不符合常规套路的输入固化后的流程就不知道怎么变通了而原始Agent至少还能灵活调整。正确做法是在拆解运行轨迹时多问自己一个“为什么”。比如前面调研Agent的“生成搜索子主题”这一步本质上是在完成“把模糊的产品名转成一组精准的检索词”这个思考动作。如果我只是把这一步的原样逻辑固化下来它就没有“根据产品词灵活调整检索词”的能力了。所以这一步我保留成模型调用而不是处理成模板。5.3 坑三制品没有版本管理迭代一次就翻一次车制品是活的资产不是一次成型后就固定不变的文件。我今天发现调研维度需要加一个“价格策略”明天发现过滤逻辑需要调整阈值后天可能发现一个新的信息源更好用。如果每次改动都直接改原有的流程不记录版本改出问题之后连回滚都很难。我的做法是把每一个制品当做一个独立项目来管理用版本控制工具管理每次配置的变更把版本更新记录写成文档标注清楚改动原因和验证结果。可能听起来有点重但你只要被一个制品坑过一次就会明白这比在泥潭里排查半天省力得多。5.4 坑四过于追求太长的提示词反而挤垮了输出质量有些人在做提示词固化的时候恨不得把Agent整个思考过程全部塞进提示词里试图让单次模型调用复现Agent的全部智能。我试过结果很惨——超过一定长度后模型根本“看不过来”这么多约束输出质量急剧下降甚至开始自相矛盾。一个实用的经验是一个提示词里只集中约束一个决策点输出才能可靠。如果你需要给模型交代多种职责、多种格式、多种边界那通常说明你的制品结构没拆够——应该把这个提示词拆成多个更小的决策点分散到工作流的多个步骤里每个步骤只解决一个问题。这本质上就是把大模型的高自由度推理拆成小模型的低成本推理。写在最后的一点体会做了这么多实验我现在越来越确信Agent的真正价值不完全在于它每一次的“临场发挥”而在于它能不能把临场发挥的成果留下来变成不用思考就能用、用了就有效果的东西。我见过太多的Agent项目在验证期惊艳却在规模化之后折戟就是因为大家都把注意力放在“怎么让Agent更聪明”上很少有人关心“怎么让Agent的聪明被固化下来”。如果你现在手头有一个Agent应用正在被成本和稳定性困扰我的建议是别急着换更大更强的模型也别急着把推理链路全部砍掉。花一点时间把Agent的运行轨迹录下来把里面那些已经稳定的判断抽出来做成哪怕是很粗糙的制品你的成本会降下来稳定性会提上去而且你会第一次真正感觉到那个每次都要认真对待才能解决问题的Agent终于变成了一个可以装进瓶子、随时拿出来用的小工具。我自己已经把这套方法用在了调研、数据清洗、内容生成三个方向上下一步准备把手头几个稳定的制品互相组合看看能不能在“制品编排”这个方向上再挖出点东西来。这个方向我想会有越来越多的人涌进来早一点把基本功练扎实后面会从容很多。