1. 项目概述当Agent“卸下重担”LLM还剩多少活儿最近在搞Agent架构设计特别是那种基于LLM的规划型智能体一个绕不开的核心问题总在脑子里打转我们到底在多大程度上“依赖”或者说“压榨”了LLM当我们把任务规划、工具调用、状态跟踪这些“重活”都交给一个精心设计的Agent框架比如Harness、LangChain这类去处理时中间那个大语言模型本身它到底还承担了多少实质性的“思考”工作这个问题的答案直接关系到我们如何设计Agent、如何评估其能力边界、以及最终如何为这个系统分配计算资源和成本。简单来说这个项目想探讨的就是在一个成熟的规划型Agent中LLM的“剩余角色”究竟有多大。我们给Agent套上了缰绳Harness让它能按照声明式规划Declarative Planning的蓝图去一步步执行任务那么LLM本身是从全能的大脑退化成仅仅执行指令的“手”还是依然在幕后进行着不可替代的深度推理这不仅仅是学术好奇更是工程实践中的灵魂拷问。如果你正在构建或使用AI Agent理解LLM在其内部的真实工作负荷能帮你更好地做架构选型、性能优化和成本控制。2. 核心思路拆解Agent工作流定位LLM的“出力点”要测量LLM的剩余角色我们不能泛泛而谈必须深入到Agent的具体工作流中去。一个典型的、基于LLM的规划型Agent其生命周期通常可以分解为几个核心阶段。我们的测量就是要在每个阶段“插上探针”看看LLM到底输出了什么、输出了多少。2.1 典型规划型Agent的工作阶段分解首先我们得建立一个共识性的Agent工作模型。虽然不同框架如LangChain的AgentExecutor、AutoGPT的架构、或是自定义的Harness在实现细节上各有不同但其核心逻辑链是相通的。我将其概括为以下四个主要阶段任务理解与目标解析Agent接收到一个自然语言描述的用户请求例如“帮我分析一下上季度销售数据找出表现最好的三个产品并给出下季度的营销建议”。在这个阶段LLM需要理解用户的意图并将其转化为一个或多个明确的、可执行的目标。规划生成与步骤分解基于解析出的目标Agent需要制定一个行动计划。这可能是简单的线性步骤也可能是包含条件判断的复杂流程图。这就是“规划”的核心。LLM在此处的作用是生成这个计划或者在一个由框架提供的规划模板即Declarative Planning的“声明”中进行填充和实例化。子任务执行与工具调用计划中的每一个步骤都可能涉及调用外部工具或API如查询数据库、执行计算、调用搜索引擎、操作文件系统等。LLM需要理解当前步骤的要求生成调用特定工具所需的正确参数例如生成一个精确的SQL查询语句或一个符合格式要求的API调用参数。结果整合与响应生成所有子任务执行完毕后会得到一系列中间结果。LLM需要综合这些信息进行总结、分析、推理最终生成一个面向用户的、连贯且完整的自然语言响应。2.2 “Harness”与“Declarative Planning”如何介入“Harness”在此语境下可以理解为一种约束、引导或框架和“Declarative Planning”声明式规划是减少LLM工作负荷的两个关键工程思想。Harness约束框架它通过预设的规则、状态机、工具目录和调用规范极大地限制了LLM的“行动范围”。LLM不需要从零开始“发明”如何调用工具它只需要在框架给定的选项中进行选择并填写参数。这就像给一个经验丰富的司机一张详细的交规手册和GPS导航他不需要自己探索道路规则和规划所有路径只需专注于驾驶操作。Harness将大量结构化的、重复性的决策逻辑从LLM中剥离固化在框架代码里。Declarative Planning声明式规划这是规划阶段的一种高效方法。我们不再要求LLM每次都为任务“从头编写”一个计划而是预先定义好一些通用的计划模板或模式例如“数据分析任务”的模板可能固定包含“获取数据-清洗数据-分析数据-可视化-总结”这几个阶段。用户或开发者以“声明”的方式描述目标LLM的工作就变成了将声明映射到最合适的模板并对模板中的变量进行填充。这极大地降低了规划阶段对LLM创意和复杂推理能力的要求。理解了这两个概念我们测量LLM“剩余角色”的思路就清晰了我们需要评估在引入了强大的Harness和Declarative Planning机制后上述四个工作阶段中哪些环节仍然必须、且主要地依赖LLM的核心能力如深层语义理解、复杂推理、创造性生成哪些环节已经可以被框架规则和模板所替代或大幅简化。3. 测量方法论从定性观察到定量指标测量不能只靠感觉我们需要一套可操作的方法。我将测量分为两个层面定性观察和定量指标。定性观察帮助我们理解LLM在“质”上做了什么定量指标则试图在“量”上进行刻画。3.1 定性观察LLM的“不可替代性”体现在哪里即使有完善的框架LLM在以下环节的参与仍然是深刻且难以完全替代的模糊意图的澄清与细化用户的需求常常是模糊、不完整或隐含的。例如“帮我做一下竞品分析”。Harness可以提供“竞品分析”的模板但LLM需要通过与用户的多轮对话或基于上下文的理解来明确分析哪些竞品关注哪些维度价格、功能、市场份额时间范围是什么输出形式是什么这种基于对话的意图澄清和需求细化高度依赖LLM的语境理解和共情能力。非结构化信息到结构化参数的映射这是工具调用环节的核心挑战。用户说“找一下最近关于AI芯片的新闻”Harness知道可以调用“新闻搜索”工具。但LLM需要将“最近”映射为具体日期范围如“过去7天”、“AI芯片”映射为一系列关键词和同义词如“GPU, TPU, NPU, 人工智能芯片”这些非结构化描述转化为搜索引擎能理解的结构化查询参数。这个映射过程充满了歧义和上下文依赖。跨工具结果的融合与推理假设一个任务先后调用了数据库查询得到销售数字和情感分析API得到客户评论情感倾向。LLM拿到这两个结果后需要建立它们之间的关联“虽然A产品销售额高但客户情感倾向为负面这可能意味着市场饱和或存在未解决的投诉而B产品销售额一般但情感积极可能有增长潜力。”这种跨域信息的连接、对比和深层推理是框架规则难以预先定义的必须依赖LLM的推理能力。应对计划外异常与创造性调整再完美的Declarative Planning模板也无法覆盖所有情况。当工具调用失败、返回意外结果、或遇到前所未见的情景时LLM需要有能力进行临场判断调整原有计划甚至生成全新的解决方案步骤。这种适应性和小范围的创造性是LLM剩余角色的关键体现。3.2 定量指标尝试给LLM的“工作量”标价定性分析告诉我们LLM还在“动脑子”但动了多少呢我们可以尝试设计一些间接的定量指标来评估Token消耗分布分析这是最直接的指标。在Agent的完整运行周期中记录下总共消耗的Prompt Tokens和Completion Tokens。然后进一步细分系统提示词Harness/框架规则占比这部分是固定的不依赖具体任务代表了框架承担的工作量。规划阶段Token消耗在生成或适配计划时消耗的Token。工具调用参数生成Token消耗为每个工具调用生成输入参数所消耗的Token。结果整合与响应生成Token消耗。 通过分析各阶段的Token占比可以直观看出LLM的“算力”主要用在了哪个环节。如果工具调用参数生成占比极高说明LLM在“翻译”工作上负担重如果结果整合占比高说明复杂推理任务重。规划模板的匹配率与填充度对于Declarative Planning我们可以统计有多少比例的用户任务能够被现有的声明式模板直接匹配在匹配的案例中模板中的变量需要LLM填充的空位占整个计划内容的百分比是多少匹配率越高、填充度越低说明LLM在规划阶段的“剩余角色”越小。工具调用的成功与重试率记录LLM生成的工具调用参数在第一次尝试时就成功的比例。如果首次调用成功率低需要框架触发重试或修正这说明LLM在理解任务和生成精确参数上遇到了困难其“工作质量”有待商榷但“工作量”因为重试可能增加了。人工干预频率在Agent运行过程中需要人工介入进行澄清、纠正或直接提供答案的频率。这个频率越高说明当前框架和LLM组合的自主性越低LLM在现有框架下独立完成核心工作的能力越有限。注意这些定量指标并非完美。Token消耗不能完全等价于“认知负荷”一个精妙的短提示可能引发LLM大量的内部计算我们无法直接观测。但它们提供了相对客观、可比较的测量维度。4. 实验设计与实操构建一个可测量的评估Harness理论说得再多不如动手实验。为了实际测量我们需要构建一个简单的、可插拔的评估框架。这个框架本身也是一个Harness它的核心任务是拦截、记录和分析Agent与LLM之间的所有交互。4.1 搭建一个带监控的Agent运行环境假设我们使用LangChain作为基础框架以下是一个高度简化的概念性实现步骤定义核心Agent创建一个具备规划能力的Agent例如使用PlanAndExecuteAgent或者自定义一个ReAct风格的Agent。为其配备一组明确的工具如计算器、网页搜索、数据库查询等。实现Declarative Planning模板创建几个JSON或YAML格式的计划模板。例如{ template_name: data_analysis, steps: [ {action: query_database, description: 获取原始数据集查询条件用户输入条件}, {action: clean_data, description: 清洗数据处理缺失值和异常值}, {action: calculate_metrics, description: 计算关键指标如指标列表}, {action: generate_summary, description: 生成分析总结报告} ] }让LLM的任务是将用户请求匹配到模板并填充...中的变量。植入监控中间件这是关键。我们需要在LangChain的调用链中插入自定义的CallbackHandler。这个Handler会捕获所有关键事件on_llm_start: 记录每次向LLM发送的完整提示Prompt。on_llm_end: 记录LLM返回的完整内容Completion并计算Token数可通过API或本地模型估算。on_tool_start/end: 记录工具调用的名称、输入参数和返回结果。on_chain_start/end: 记录规划、执行等不同链Chain的开始与结束。设计测试任务集准备一组具有代表性的测试任务涵盖不同复杂度简单任务直接匹配模板参数明确。例“计算2023年Q1的销售总额”中等任务需要意图澄清或多步规划。例“对比一下产品A和B在过去一年的市场表现”复杂任务涉及异常处理或创造性推理。例“刚才的查询失败了因为数据库连接超时请尝试另一种方法获取类似数据并完成分析”4.2 运行实验与数据收集运行测试任务监控中间件会将所有交互日志结构化地保存下来例如保存为JSONL格式。每一条日志都包含时间戳、事件类型、关联的LLM输入输出、工具输入输出、所属的任务ID等。一个简化的事件日志可能长这样{ task_id: task_001, event: on_llm_start, step: planning, prompt: 用户请求分析上季度销售数据。请从以下模板中选择最合适的一个并填充变量..., timestamp: 2023-10-27T10:00:00Z }, { task_id: task_001, event: on_llm_end, step: planning, completion: 匹配模板data_analysis。填充变量用户输入条件 - 时间段为上季度指标列表 - 销售额销售量同比增长率。, estimated_prompt_tokens: 150, estimated_completion_tokens: 80, timestamp: 2023-10-27T10:00:02Z }4.3 数据分析与可视化收集到数据后我们就可以进行计算和可视化Token消耗饼图按“系统提示”、“规划”、“工具调用参数生成”、“结果整合”等类别统计每个任务的总Token消耗并计算百分比。对比不同复杂度任务下的分布差异。模板使用统计计算测试集中任务被成功匹配到声明式模板的比例。分析未被匹配的任务的特点它们是否要求LLM进行“从零生成”规划工具调用链路图对于每个任务绘制出其完整的执行链路标注每个环节是LLM决策还是框架规则决策。这能直观展示“自动化”与“LLM介入”的边界。异常与重试分析统计工具调用失败次数、LLM生成内容导致后续步骤出错如参数格式错误的次数以及系统触发重试或回滚的频率。通过这套流程我们就能从一个相对系统的视角回答“LLM的剩余角色有多大”这个问题。你会发现对于简单、规范的任务LLM的角色可能被压缩到仅剩30%-40%主要花在参数映射和最终总结上而对于复杂、开放的任务这个比例可能飙升到70%以上LLM依然是整个系统的“CPU”。5. 核心发现与工程启示基于上述方法和实验这里综合了行业观察和个人项目经验我们可以得出一些有普遍意义的结论这些结论对设计和使用Agent具有直接的指导价值。5.1 LLM的剩余角色一个光谱而非定值LLM在规划型Agent中的工作量不是一个固定数字而是一个动态范围。它强烈依赖于任务领域与规范性在高度结构化的领域如SQL生成、数据提取良好的Harness和模板可以承担大部分工作LLM退化为“语法翻译器”。在开放领域如创意写作、战略分析LLM的核心推理角色无可替代。Harness/框架的成熟度框架预设的规则越完善、工具封装得越好、计划模板越贴近业务场景LLM需要做的“创造性”工作就越少。对可靠性与成本的权衡有时为了追求极致的可靠性如金融、医疗场景我们会故意用更严格的规则去限制LLM的自由度哪怕因此需要设计更复杂的框架逻辑。这本质上是在用工程复杂度框架代码去置换LLM的不可预测性。5.2 对Agent架构设计的启示投资于“厚”的Harness和“富”的声明式知识库不要指望用一个“万能”的LLM提示词解决所有问题。将领域知识、业务流程、常见错误处理模式尽可能多地沉淀为框架内的规则和模板。这相当于为LLM修建了高质量的高速公路让它跑得更快更稳。这就是“Harness Engineering”的核心价值。实施分层或模块化的LLM调用策略不是所有步骤都需要调用最强大也最昂贵的LLM。可以考虑任务路由用一个轻量级、快速的模型或基于规则的分类器先判断任务类型再决定使用哪个规划模板或调用哪个专用链。步骤专用模型对于简单的参数填充可以使用小模型对于复杂的综合推理再使用大模型。这种混合模型策略能显著优化成本和速度。设计良好的“人机回环”接口承认LLM能力的边界。当置信度低、或遇到框架未定义的异常时系统应能优雅地暂停并请求人工干预。干预的结果用户的纠正或确认应该能被反馈回系统用于优化未来的模板或规则形成闭环学习。5.3 对评估与优化的启示超越端到端成功率不要只盯着“任务最终是否成功完成”这个二元指标。要深入分析成功或失败的原因。是规划错了还是工具参数错了或是结果总结得不好通过我们前面提到的监控和测量方法定位瓶颈环节。建立成本-效能分析模型将Token消耗直接对应API成本与任务复杂度、完成质量关联起来。计算“每单位复杂任务的完成成本”。这能帮你判断当前架构下LLM的“剩余角色”所带来的价值是否匹配其消耗的成本。有时增加一些工程复杂度更智能的框架虽然开发成本上升但能大幅降低持续的LLM调用成本总账是划算的。持续迭代模板与规则将Agent的运行日志作为优化素材。经常分析那些导致LLM“费力”思考或出错的案例。看看是否能将这些案例抽象成新的规则或补充到现有的声明式模板中从而让系统下次遇到类似情况时能更轻松地处理。6. 常见陷阱与避坑指南在实际操作中测量和优化LLM的剩余角色会遇到不少坑。这里分享几个我踩过的或者看到别人常踩的坑。6.1 误区一追求极致的“去LLM化”问题有些人认为Harness越强越好最好能让LLM只做“填空题”彻底变成执行引擎。这可能导致系统极度僵化无法处理任何模板外的情形用户体验很差。避坑记住Harness的目的是“赋能”和“引导”LLM而不是“取代”它。要保留LLM处理模糊性和应对未知的“逃生通道”。一个好的设计是在严格规则的主干道旁边留出由LLM自主处理的“应急车道”。例如当任务与所有模板的匹配度都低于某个阈值时自动切换到一个更通用的、赋予LLM更多自由的规划模式。6.2 误区二忽视提示词工程在Harness内的作用问题以为有了框架提示词就可以随便写写了。实际上即使在强大的Harness内给LLM的指令如何理解模板、如何填充变量、如何格式化工具参数依然至关重要。一个糟糕的提示词会让LLM即使面对完美的模板也产生垃圾输出。避坑将Harness内部的提示词也视为需要精心设计和迭代的“配置”或“代码”。对它们进行版本控制、A/B测试。例如可以设计两套不同的“变量填充”提示词在相同任务上测试看哪套生成的参数更准确。框架提供了结构但提示词决定了LLM在这个结构内如何思考。6.3 误区三测量指标单一化问题只关注总Token数或总耗时忽略了细粒度的分布。可能总Token数下降了但代价是规划模板变得极其复杂和难以维护将复杂度从LLM转移到了框架开发者身上或者任务失败率上升了。避坑采用多维度的评估体系。至少应包括成本维度总Token、各阶段Token分布、质量维度任务成功率、结果人工评分、效率维度任务端到端耗时、人工干预频率、系统维度框架代码复杂度、模板维护成本。要追求的是在多个维度上的最佳平衡而不是单个指标的极端优化。6.4 误区四忽略了工具本身的质量问题工具调用失败就怪LLM生成的参数不对。但很多时候问题是出在工具API本身的不稳定、文档不清、或者错误信息不友好上。避坑在评估LLM的“工具调用参数生成”能力时首先要确保工具层是健壮的。为关键工具编写完善的模拟器Mock或测试套件在隔离的环境下测试LLM生成的参数是否真的能被工具正确处理。建立工具的“健康度”监控区分是LLM的问题还是工具后端的问题。测量LLM在Agent中的剩余角色不是一个一劳永逸的学术问题而是一个持续的工程实践。它要求我们像调试一个分布式系统一样去观察、插桩、分析智能体这个“黑盒”系统内部的信息流动和计算分布。这个过程本身就是深化我们对AI Agent能力认知的最佳途径。每一次对LLM工作负荷的精准测量和优化都让我们向构建更高效、更可靠、更经济的智能体系统迈进一步。