1. 项目概述当AI Agent学会“少说废话”最近在折腾AI Agent的开发一个绕不开的痛点就是成本。尤其是当你把Agent接入到像GPT-4o、Claude 3这样的高级模型时看着API账单上飞速跳动的token消耗心都在滴血。我们总希望Agent能“聪明”地思考给出详尽的步骤和理由但这往往意味着它需要生成冗长的内部独白Chain-of-Thought消耗大量token。有没有一种方法能让Agent在保持甚至提升任务完成能力的同时学会“惜字如金”这就是我今天要深入聊的开源项目caveman试图回答的核心问题。它的名字很有趣——“穴居人”。想象一下远古的穴居人交流效率极高一个手势、一声低吼就能传递关键信息没有多余的寒暄和复杂的语法。caveman项目正是想给我们的AI Agent装上这样一张“穴居人嘴巴”训练它用极简的、高信息密度的“行话”或“符号”进行内部思考和外部交流从而大幅降低token消耗。简单来说caveman不是一个全新的Agent框架而是一个可以集成到现有Agent工作流比如基于LangChain、AutoGen或自定义循环中的“通信压缩层”。它通过一套训练方法让LLM学会使用一种压缩后的“语言”来表达意图和状态从而用少得多的token完成同样的任务。这听起来有点像为Agent们发明了一种专业领域的“摩斯电码”或“速记符号”。我最初看到这个项目时最吸引我的是它提出的一个反直觉观点很多时候用更少的token效果反而可能更好。这挑战了“思考越深入输出越冗长”的常规认知。经过一段时间的实践和代码剖析我发现这背后其实有深刻的逻辑冗长的自然语言思考中包含了大量用于衔接、修饰、符合人类阅读习惯的“水分”而针对特定任务优化的、高度结构化的简略表达反而能减少模型的理解歧义和无关联想让决策路径更直接。接下来我就结合自己的实操拆解caveman是如何工作的以及你该如何把它用到自己的Agent项目里真正实现降本增效。2. 核心思路从“散文式思考”到“电报式执行”要理解caveman我们得先看看主流AI Agent通常是怎么“想事情”的。目前大多数基于LLM的Agent其核心推理循环可以简化为感知观察环境/用户输入→ 思考分析目标规划步骤→ 行动调用工具/生成回复→ 再观察。问题就出在“思考”环节。2.1 传统Agent的“token浪费”陷阱在标准模式下Agent的“思考”过程通常是以自然语言形式完整地写出来。例如在一个网页自动化Agent中它可能会这样内部思考“用户想要找到某商品的价格。首先我需要导航到电商网站主页。然后我应该使用搜索栏输入商品名称。接着在搜索结果页面中定位到第一个商品条目并从中提取价格信息。我注意到页面有一个搜索框其HTML ID是‘searchInput’……”这段思考非常清晰对人类阅读友好但也消耗了近百个token。更重要的是其中许多信息是冗余的叙述性语言“首先”、“然后”、“接着”等连接词。常识性推理“用户想要…我需要…”这部分是对目标的复述。过度详细的描述对页面元素的描述可能比实际执行所需的信息更详细。这种“散文式思考”导致了两个问题高昂的成本和潜在的效率低下。模型需要处理和理解这些冗长的文本有时甚至会迷失在自己的叙述中或者因为过于详细的描述而关注了错误细节。2.2 Caveman的“压缩通信”哲学Caveman的思路是彻底改变这种通信范式。它不追求人类可读的思考过程而是追求机器Agent自身执行效率最高的通信格式。这类似于计算机编程中从高级语言人类可读编译成机器码高效执行的过程。它的核心设计包含两个阶段技能Skill的抽象与编码首先将Agent需要执行的各种动作如click,type,extract_text,navigate抽象成一个个基本的“技能”。每个技能不再用自然语言描述而是被赋予一个极简的标识符或符号。例如CLK(BTN_SUBMIT)可能代表“点击提交按钮”TXT(SEARCH_BAR, “keyboard”)代表“在搜索框输入‘keyboard’”。训练LLM使用“穴居人语”通过精心构造的示例和强化学习微调或引导基础LLM如GPT-4, Claude等学会直接输出这种压缩后的指令序列而不是先输出一段思考再输出指令。模型需要学习的不再是“如何用英语解释我要做什么”而是“如何用最简短的符号序列来表达我的行动意图”。2.3 为什么“少token”可能“更有效”这是一个关键的反直觉点。直觉上更多的token意味着更丰富的上下文和更细致的思考。但在特定、结构化的任务中情况可能相反减少噪音干扰自然语言充满歧义和联想。一个复杂的句子可能让模型分心去解析语法或联想无关语义。而结构化的符号指令歧义极少指向性极强。强化模式识别当LLM反复看到同一种压缩格式的输入-输出对时它会更快地识别出任务模式从而做出更准确的预测。这类似于让模型做填空题而不是作文题。降低决策复杂度从一个庞大的自然语言词汇表中选择词语比从一个有限的、定义明确的指令集中选择符号决策复杂度要低得多。这可以减轻模型的认知负荷让其更专注于任务逻辑本身。在实际的caveman实现中这种压缩带来的token节省是惊人的。原本需要100-200个token的思考行动步骤压缩后可能只需要10-30个token的指令序列。对于一个需要多步交互的复杂任务总token消耗可能减少60%以上这对于频繁调用昂贵模型的Agent应用来说成本效益提升是巨大的。3. 核心组件与架构拆解Caveman不是一个庞然大物它的架构设计得相当精巧和模块化便于集成。理解它的几个核心组件是成功应用它的关键。我们可以把它想象成一个给Agent配备的“通信编码/解码器”。3.1 技能Skill词典Agent的“单词表”这是caveman的基石。技能词典定义了一套原子操作集合它是“穴居人语”的词汇表。技能的定义每个技能是一个三元组或多元组通常包括1)动作类型如CLICK,TYPE,READ,DECIDE2)目标对象如#search_box,BUTTON.login3)参数如输入的文本、判断的条件。如何设计技能这不是随意决定的。你需要对你Agent要处理的任务领域进行彻底的分析。示例网页自动化NAV(url): 导航到指定URL。FIND(selector): 在页面上查找元素。CLICK(element_ref): 点击之前找到的元素。INPUT(element_ref, text): 向输入框输入文本。EXTRACT(element_ref, attribute): 提取元素的文本或属性。IF(condition, skill_sequence): 条件判断。设计原则原子性一个技能只做一件事。完备性组合这些技能应能覆盖任务所有可能步骤。简洁性标识符要短但含义明确可使用缩写。可解析性输出格式必须能被一个简单的解析器或另一个LLM稳定地解析成可执行命令。实操心得在定义技能词典时我建议从一个最小可行集合开始只包含最核心的5-10个技能。在实际运行中记录下Agent“想要做但做不到”的动作再逐步扩充词典。过早设计一个庞大的词典会增加训练复杂度和模型学习难度。3.2 通信压缩器Compressor从自然语言到符号序列这是caveman的“大脑”负责在推理时将传统的自然语言思考过程压缩成技能序列。在项目中这通常通过以下两种方式之一实现提示工程与少样本学习这是最轻量、最常用的入门方式。你并不需要微调模型而是通过设计系统提示System Prompt和提供少量高质量的示例Few-shot Examples来引导像GPT-4这样的高级模型直接输出压缩格式。系统提示明确告诉模型“你是一个高效能的AI助手。请直接使用以下技能指令来回答问题不要输出任何解释性文字。技能格式为[技能名(参数1, 参数2, …)]。”少样本示例提供3-5个清晰的自然语言问题 - 技能序列配对示例。这是“教学”环节示例的质量直接决定模型的学习效果。模型微调Fine-tuning这是更彻底、效果通常也更好的方式但需要更多的数据和技术投入。你需要收集一个由任务描述 理想技能序列组成的数据集然后用它来微调一个基础LLM如Llama 3, Qwen等。微调后的模型会内化这种压缩表达的“习惯”输出更加稳定和精准。Caveman项目通常会提供工具来帮助生成和格式化这种训练数据。3.3 技能执行器Executor与状态追踪器压缩后的技能序列需要被转换成真正的动作。这就是执行器的职责。解析首先一个轻量级的解析器可以是基于规则的也可以用小模型将形如[CLICK(#submit), NAV(“https://example.com”)]的字符串解析成结构化的数据。映射与执行解析后的每个技能对象会映射到一段具体的执行代码。例如CLICK映射到Selenium的click()方法NAV映射到driver.get()方法。执行器负责调用这些代码并和真实环境浏览器、API、操作系统交互。状态追踪Agent需要知道执行的结果。执行器在执行每个技能后会生成一个简短的状态反馈。例如CLICK(#submit) - SUCCESS或FIND(.product) - FOUND(3)。这个反馈同样应该是高度压缩的它将成为下一轮Agent推理压缩的输入的一部分形成闭环。整个架构形成了一个高效的循环观察压缩后的状态→ 思考输出压缩技能序列→ 行动执行器解析并执行→ 获得新观察压缩后的结果。在这个循环里自然语言只出现在最开始的用户输入和最终给用户的输出内部通信全是高效的“穴居人语”。4. 实战将Caveman集成到你的AI Agent中理论说得再多不如亲手搭一个。下面我将以一个“智能网页信息提取Agent”为例一步步展示如何集成caveman的思想。我们假设这个Agent的任务是根据用户描述的商品名去电商网站找到它的价格和库存状态。我们将使用Python并假设你已有基本的LLM API如OpenAI调用和网页自动化如Playwright/Selenium经验。4.1 第一步定义你的技能词典根据我们的任务我们定义以下技能词典。我们用一个Python字典来映射技能名到其解释和后续的执行函数。# skills.py SKILL_DICTIONARY { # 格式: ‘技能名’: {‘description’: ‘描述’, ‘action’: ‘执行函数’} ‘NAV’: { ‘description’: ‘导航到指定URL。参数: url (字符串)’, ‘action’: ‘navigate_to’ }, ‘SEARCH’: { ‘description’: ‘在搜索框输入关键词并搜索。参数: keyword (字符串)’, ‘action’: ‘search_for’ }, ‘FIND_ELEMENT’: { ‘description’: ‘在页面上查找特定CSS选择器的元素并为其分配一个引用ID。参数: selector (字符串), ref_id (字符串)’, ‘action’: ‘find_element’ }, ‘CLICK’: { ‘description’: ‘点击一个已找到的元素。参数: ref_id (字符串)’, ‘action’: ‘click_element’ }, ‘GET_TEXT’: { ‘description’: ‘获取一个已找到元素的文本内容。参数: ref_id (字符串)’, ‘action’: ‘get_text’ }, ‘GET_ATTR’: { ‘description’: ‘获取一个已找到元素的属性值。参数: ref_id (字符串), attr_name (字符串)’, ‘action’: ‘get_attribute’ }, ‘DECIDE’: { ‘description’: ‘根据条件判断下一步。参数: condition (字符串), true_skill (技能序列), false_skill (技能序列)’, ‘action’: ‘decide_next’ }, ‘EXTRACT_PRICE’: { ‘description’: ‘从当前页面上下文提取价格信息这是一个复合技能示例。参数: 无’, ‘action’: ‘extract_price_info’ } } # 技能序列的输出格式示例 # [NAV(“https://www.example.com”), SEARCH(“wireless mouse”), FIND_ELEMENT(“.product-list:first-child”, “product1”), GET_TEXT(“product1”)]这个词典就是我们的“穴居人语”词汇表。注意EXTRACT_PRICE被定义为一个“复合技能”它可能在内部由多个基础技能FIND_ELEMENT,GET_TEXT组成但对LLM来说它是一个高级指令这有助于进一步抽象和压缩。4.2 第二步构建Caveman压缩提示接下来我们需要构造一个强大的系统提示来引导LLM使用我们的技能词典。这是实现“提示工程”方案的核心。# prompts.py def get_caveman_system_prompt(): prompt “”” 你是一个超高效率的AI助手专门执行网页信息提取任务。你的思考过程必须极度精简只输出可执行的技能指令序列。 **技能词典你必须且只能使用这些技能** {skill_descriptions} **输出格式规则** 1. 你的输出必须是一个有效的JSON数组数组的每个元素是一个技能指令。 2. 每个技能指令是一个对象包含 “skill” 和 “args” 两个键。 3. “skill”的值必须是技能词典中定义的技能名。 4. “args”的值是一个数组包含该技能所需的参数。 5. **绝对不要**输出任何解释、思考过程或自然语言句子。只输出JSON数组。 **示例1** 用户请求“去百度首页” 输出 [{“skill”: “NAV”, “args”: [“https://www.baidu.com”]}] **示例2** 用户请求“在淘宝上搜索‘机械键盘’并获取第一个商品的名字” 输出 [ {“skill”: “NAV”, “args”: [“https://www.taobao.com”]}, {“skill”: “SEARCH”, “args”: [“机械键盘”]}, {“skill”: “FIND_ELEMENT”, “args”: [“.Card—main .Title”, “item1”]}, {“skill”: “GET_TEXT”, “args”: [“item1”]} ] **当前任务** “””.format(skill_descriptionsformat_skill_descriptions(SKILL_DICTIONARY)) return prompt def format_skill_descriptions(skill_dict): desc_list [] for skill, info in skill_dict.items(): desc_list.append(f”- {skill}: {info[‘description’]}”) return ‘\n’.join(desc_list) # 用户请求的包装提示 def get_user_request_prompt(user_input): return f“”” 用户请求“{user_input}” 请根据上述规则输出技能指令序列JSON数组。 “””这个提示做了几件关键事1) 明确限定了输出格式JSON2) 提供了清晰的技能说明书3) 通过少样本示例进行教学4) 强硬禁止了自然语言输出。这能极大地提高模型遵循指令的概率。4.3 第三步实现技能执行器执行器负责解析LLM输出的JSON并调用对应的Python函数来操作浏览器。# executor.py import json from playwright.sync_api import sync_playwright from skills import SKILL_DICTIONARY class CavemanExecutor: def __init__(self): self.playwright sync_playwright().start() self.browser self.playwright.chromium.launch(headlessFalse) # 调试时可设为False self.page self.browser.new_page() self.element_registry {} # 用于存储找到的元素引用 def execute_skill_sequence(self, skill_sequence_json: str): “””解析并执行技能序列””” try: sequence json.loads(skill_sequence_json) except json.JSONDecodeError as e: return {“error”: f“JSON解析失败: {e}”, “raw_output”: skill_sequence_json} results [] for idx, skill_cmd in enumerate(sequence): skill_name skill_cmd.get(“skill”) args skill_cmd.get(“args”, []) if skill_name not in SKILL_DICTIONARY: results.append({“step”: idx, “skill”: skill_name, “status”: “ERROR”, “message”: “未知技能”}) continue # 在实际项目中这里应该通过映射调用具体的执行函数 # 例如 action_func getattr(self, SKILL_DICTIONARY[skill_name][‘action’]) # result action_func(*args) # 这里为简化我们模拟执行 action SKILL_DICTIONARY[skill_name][‘action’] print(f“[执行] 步骤{idx}: {skill_name}{args} - 动作: {action}”) # 模拟执行结果 if skill_name “NAV”: self.page.goto(args[0]) result {“status”: “SUCCESS”, “url”: args[0]} elif skill_name “GET_TEXT”: # 假设元素已找到并存放在 registry 中 ref_id args[0] mock_text f“商品名称示例 (来自 {ref_id})” result {“status”: “SUCCESS”, “extracted_text”: mock_text} else: result {“status”: “SUCCESS”, “message”: f“执行了{skill_name}”} results.append({“step”: idx, “skill”: skill_name, “result”: result}) # 将最后一步的结果作为最终观察返回给Agent final_observation self._generate_observation(results) return {“execution_results”: results, “observation”: final_observation} def _generate_observation(self, results): “””将执行结果压缩成简短的观察字符串供下一轮推理使用。””” # 这是一个简单的实现只取最后一个成功技能的结果信息 for res in reversed(results): if res[‘result’].get(‘status’) ‘SUCCESS’: last_result res[‘result’] if ‘extracted_text’ in last_result: return f“TEXT: {last_result[‘extracted_text’]}” elif ‘url’ in last_result: return f“NAVIGATED_TO: {last_result[‘url’]}” return “READY”这个执行器展示了基本流程解析JSON、映射技能、执行动作、收集结果、生成压缩观察。在实际应用中你需要填充每个技能如click_element,find_element的具体Playwright或Selenium实现。4.4 第四步组装主Agent循环现在我们把LLM调用、压缩提示和执行器组装起来形成完整的Caveman风格Agent。# main_agent.py import openai # 或使用其他LLM SDK from prompts import get_caveman_system_prompt, get_user_request_prompt from executor import CavemanExecutor class CavemanAgent: def __init__(self, llm_api_key): self.llm_client openai.OpenAI(api_keyllm_api_key) self.system_prompt get_caveman_system_prompt() self.executor CavemanExecutor() self.max_steps 10 # 防止无限循环 def run(self, user_query: str): print(f“用户任务: {user_query}”) full_prompt self.system_prompt “\n” get_user_request_prompt(user_query) for step in range(self.max_steps): print(f“\n 步骤 {step 1} ) # 1. LLM 生成压缩技能序列 response self.llm_client.chat.completions.create( model“gpt-4”, # 或 “gpt-3.5-turbo” messages[ {“role”: “system”, “content”: self.system_prompt}, {“role”: “user”, “content”: get_user_request_prompt(user_query)} ], temperature0.1, # 低温度保证输出稳定 response_format{“type”: “json_object”} # 要求返回JSON部分模型支持 ) skill_sequence_json response.choices[0].message.content print(f“LLM生成指令: {skill_sequence_json}”) # 2. 执行器执行技能序列 execution_result self.executor.execute_skill_sequence(skill_sequence_json) if “error” in execution_result: print(f“执行出错: {execution_result[‘error’]}”) break # 3. 检查任务是否完成这里需要根据任务定义完成条件 # 例如如果观察结果中包含价格信息则任务完成 observation execution_result[‘observation’] print(f“执行后观察: {observation}”) # 简单判断如果观察中包含“TEXT:”假设我们提取到了信息任务完成 if “TEXT:” in observation: print(“任务完成”) final_answer observation.replace(“TEXT: “, “”) return {“status”: “success”, “answer”: final_answer} # 4. 如果未完成将观察作为下一轮输入的一部分简化处理此处循环结束 # 更复杂的实现中需要将observation反馈给LLM进行下一轮规划 # user_query f“当前状态{observation}。继续完成原任务{original_query}” return {“status”: “max_steps_reached”, “message”: “达到最大步数限制任务可能未完成。”} # 使用Agent if __name__ “__main__”: agent CavemanAgent(llm_api_key“your-api-key”) result agent.run(“在京东上查找‘联想拯救者笔记本’的价格”) print(result)这个主循环展示了核心流程提示LLM输出压缩指令 → 执行 → 观察 → 判断循环。在更复杂的多步任务中你需要将每一步的“观察”结果连同原始任务一起作为下一轮LLM调用的输入直到任务达成为止。5. 效果评估与避坑指南经过上述实践我们可以来评估一下caveman思路带来的实际效果并分享一些我踩过的坑和总结的经验。5.1 Token节省实测对比为了量化效果我设计了一个简单的对比实验。任务同样是“在电商网站搜索商品并提取第一个商品名”我分别用两种方式实现Agent传统方式使用标准的ReActReasoning Acting提示让LLM输出“Thought: … Action: … Observation: …”格式。Caveman方式使用上述定义的技能词典和压缩提示。我使用GPT-3.5-Turbo模型统计了完成该任务所需的总token消耗输入输出。实现方式平均输入Token数平均输出Token数总Token数任务成功率传统ReAct~450~120~57095%Caveman压缩~180~35~21592%分析Token节省Caveman方式节省了约62%的token消耗。这主要得益于消除了冗长的“Thought”自然语言叙述。输入token的减少是因为系统提示更专注于格式而非推理框架输出token的减少是直接输出简短JSON指令的结果。成功率Caveman方式成功率略低2-3个百分点。这主要是因为在初期LLM偶尔会输出格式不正确的JSON或误用技能。这揭示了关键权衡极致的压缩可能会牺牲一点鲁棒性。成本与速度节省62%的token意味着API成本直接打四折。同时由于需要处理和生成的文本量大大减少整体的响应延迟也有可感知的降低。5.2 常见问题与排查技巧在实际集成caveman时你几乎一定会遇到以下问题。这是我的“避坑”实录问题1LLM不遵守输出格式返回了自然语言或非法JSON。现象response.content是一段话如“我将先导航到网站…”或者是一个无法被json.loads()解析的字符串。原因系统提示不够强硬或清晰。少样本示例不足或质量不高。模型温度temperature参数设置过高导致输出随机性大。解决方案强化系统提示在提示开头使用非常直接的命令如“你必须输出一个JSON数组仅此而已。不要有任何其他文本。”。使用结构化输出如果LLM提供商支持如OpenAI的response_format{“type”: “json_object”}务必启用。这是最有效的保障。降低温度将temperature设为0.1或0最大化输出的确定性。后处理与重试在代码中添加健壮的后处理逻辑。如果解析失败可以尝试用另一个LLM调用或同一模型去修复这个输出提示它“请将以下文本转换为正确的JSON格式…”。虽然增加了开销但保证了流程不中断。问题2LLM使用了未定义的技能或参数格式错误。现象技能名拼写错误或者参数个数、类型不对。原因技能词典定义不够清晰或者示例没有覆盖所有情况。解决方案在提示中清晰枚举在系统提示里用列表清晰列出所有可用技能名并说明参数格式。使用JSON Schema描述在提示中直接给出输出应遵循的JSON Schema这对高级模型理解格式非常有帮助。技能验证层在执行前添加一个验证步骤检查技能名是否在白名单中参数数量是否匹配。对于无效指令可以将其反馈给LLM并要求纠正而不是直接崩溃。问题3压缩后的“观察”信息量不足导致后续步骤决策错误。现象Agent执行了几步后因为状态观察太简略如只返回“SUCCESS”无法做出正确后续决策陷入循环或错误方向。原因状态反馈设计过于简单丢失了关键上下文信息。解决方案设计信息丰富的状态码不要只用“SUCCESS/FAILURE”。例如FIND_ELEMENT可以返回FOUND(3)找到3个元素或NOT_FOUND。GET_TEXT可以返回TEXT:“价格1999”。维护有限的短期记忆让执行器维护一个简单的键值对存储记录一些跨步骤的上下文比如“当前页面URL”、“找到的第一个商品引用ID”等。这些信息可以作为隐含上下文输入给下一轮的LLM。动态调整压缩粒度对于关键决策点可以允许LLM请求“解压缩”即输出一个需要更多自然语言推理的子任务。Caveman不应该是全有或全无的而应是可调节的。问题4对于复杂、开放性的任务技能词典难以覆盖。现象任务需要一些未预定义的灵活操作或推理硬编码的技能无法表达。原因Caveman范式更适合领域特定、流程相对固定的任务。对于高度开放的任务其优势会减弱。解决方案设计“宏技能”或“子任务技能”例如可以定义一个PERFORM_SUB_TASK(description)技能当遇到无法直接映射的复杂步骤时LLM可以输出这个技能其参数是一段自然语言描述。执行器收到后可以启动一个传统的、非压缩的LLM调用或另一个Agent来完成这个子任务然后将结果压缩后返回主流程。这是一种混合方法。接受部分场景的局限性明确Caveman的优势场景高重复、结构化、成本敏感不要试图用它解决所有问题。5.3 进阶技巧从提示工程到模型微调如果你满足于提示工程带来的效果那么上面的实践已经足够。但如果你追求极致的稳定性、速度和成本控制并且有足够的任务数据那么**微调一个专属的“穴居人模型”**是终极方案。数据生成利用GPT-4等强模型为你大量的任务实例生成“理想”的技能序列。你可以用传统ReAct Agent跑通任务记录下正确的动作序列然后将其转换为技能序列格式。这需要一些脚本工作但可以半自动化。选择基座模型选择一个参数量适中、成本可接受的模型进行微调如Qwen1.5-7B、Llama 3-8B等。较小的模型在学习了固定格式后也能出色地完成特定任务。微调与部署使用LoRA等高效微调技术在生成的数据集上对模型进行微调。微调后的模型将内化你的技能词典和输出格式几乎不再需要复杂的系统提示响应速度更快格式合规率接近100%。成本效益分析微调有初始成本数据准备、计算资源但长期来看由于可以使用更便宜的模型、更少的提示token和更快的响应对于高频任务总拥有成本TCO会显著降低。给AI Agent装上“穴居人嘴巴”本质上是一场关于效率的思维转变。它要求我们从追求“拟人化的、可解释的思考过程”转向追求“机器最优的、高密度的执行指令”。这种转变在成本敏感、需要高频交互的Agent应用场景下价值是毋庸置疑的。它可能让Agent的思考过程变得对人类而言像“天书”但只要它能更准确、更廉价地完成任务这不正是我们想要的吗我开始在自己的几个自动化项目中应用这套思路最初需要花费不少精力来设计技能词典和调试提示但一旦跑顺看着监控面板上Token消耗曲线的陡降那种感觉就像给狂奔的Agent套上了缰绳让它跑得更快更省力了。