1. 从Skills狂热到Agent本质的回归去年整个AI圈几乎被“Skills”这个词刷屏了。无论是各大AI平台的官方文档还是技术社区的分享言必称“为你的Agent添加Skills”。一时间仿佛一个AI Agent的能力强弱完全取决于它背后挂载的Skills商店里有多少个“技能插件”。开发者们热衷于收集、分享和交易各种Skills从“联网搜索”到“代码解释器”从“PDF总结”到“邮件自动回复”琳琅满目。我也曾是这股热潮的积极参与者乐此不疲地给我的Agent“装配”各种技能看着它能做的事情越来越多颇有一种在玩角色扮演游戏时给角色点技能树的快感。然而当这股热潮逐渐退去我开始冷静下来审视手头这些“超级武装”的Agent时却发现了一些不对劲的地方。我拥有一个能调用几十个API、理论上无所不能的Agent但它处理复杂任务时依然显得笨拙、低效甚至经常“精神分裂”——在不同的子任务间切换时上下文丢失逻辑断裂。这促使我重新思考我们是不是从一开始就误解了AI Agent或者说被“Skills”这个过于具象和工具化的概念带偏了方向一个真正强大、智能的Agent其核心究竟应该是什么经过一段时间的反思和重新实践我的观点发生了根本性的转变。AI Agent的方向不在于堆砌多少孤立的“技能”Skills而在于构建一个具有强大核心“心智”或“认知架构”的智能体。Skills更像是这个智能体可以熟练使用的“工具”但工具本身不能替代思考、规划和决策的能力。没有强大心智的Agent即使拥有再多的Skills也只是一个笨拙的、需要人类频繁干预的“自动点击器”而一个拥有强大心智的Agent即使初始技能有限也能通过有效的规划和学习快速掌握新工具优雅地解决复杂问题。接下来我将结合我的实践和观察详细拆解这个认知转变的过程并分享我对未来AI Agent发展方向的重新理解。2. Skills市场的繁荣与幻灭我们曾相信什么要理解现在的方向必须先复盘我们曾经走过的路。Skills热潮的兴起有其必然性和合理性它本质上降低了AI应用的门槛并催生了一个短暂的繁荣生态。2.1 Skills热潮的驱动逻辑与短期红利Skills概念的流行很大程度上源于对大型语言模型LLM能力边界的一种直观补强策略。大家很快发现尽管LLM知识渊博、能说会道但它有几个致命短板无法获取实时信息、无法执行具体操作、无法处理私有数据。于是一个自然的想法诞生了让LLM学会“调用工具”。一个“Skill”本质上就是一个封装好的、可供LLM调用的函数或API接口。这种模式带来了立竿见影的效果功能模块化开发者可以将复杂能力如发送邮件、查询数据库、生成图表封装成一个个标准的Skill接口统一通常是自然语言描述或JSON Schema便于管理和复用。生态快速形成平台方如OpenAI的GPTs、Claude的Console推出Skill市场允许开发者上传和分享自己的Skill。用户无需编码通过勾选就能赋予Agent新能力体验瞬间提升。降低了开发门槛对于很多应用场景开发者不再需要从头构建整个Agent系统只需专注于业务逻辑然后像搭积木一样组合现有的Skills大大加快了原型开发速度。我当时也深受其益。通过组合“网页爬取Skill”、“内容总结Skill”和“邮件发送Skill”我几乎在半小时内就搭建了一个自动化的行业简报生成器。这种“即插即用”的爽快感是Skills热潮最直接的吸引力。2.2 繁荣下的结构性缺陷与根本矛盾然而随着使用场景从简单、单线程的任务扩展到复杂、多步骤的流程时Skills模式的缺陷开始暴露无遗。这些问题不是某个Skill写得不好而是模式本身的结构性矛盾。缺陷一心智缺失导致的“脆弱工作流”一个仅靠Skills清单驱动的Agent其工作流程是脆弱且线性的。它通常遵循“用户输入 - LLM理解并选择Skill - 执行Skill - 返回结果 - LLM组织回答”的模式。一旦任务需要多步决策、条件分支或动态规划这种模式就崩溃了。例如我让Agent“分析某公司最新财报总结其风险点并如果风险大于机会就起草一份风险提示邮件”。一个仅有Skills的Agent可能会先调用“财报获取Skill”得到一堆数据然后试图调用“文本分析Skill”但因为数据格式或上下文丢失分析得牛头不对马嘴最后无论风险大小都机械地调用“邮件起草Skill”。它缺乏一个持续的“工作记忆”来跟踪任务目标分析风险、子任务状态数据已获取但未分析、以及决策逻辑“如果风险大于机会”这个条件判断应该在哪个环节、由谁来做。缺陷二技能协同与上下文管理的灾难当多个Skills需要协同工作时上下文Context的管理成为噩梦。每个Skill的执行都是独立的“函数调用”它接收一段输入返回一段输出。但Skill A的输出如何精准、结构化地成为Skill B所需的输入LLM需要充当一个“胶水”在自然语言间进行转换和传递这个过程极易信息失真或丢失。例如Skill A“数据查询”返回了JSON格式的销售数据Skill B“图表生成”需要特定的数据字段名。如果LLM在转述时把字段名“Q1_Revenue”错误地翻译成“第一季度收入”Skill B就会失败。这要求开发者要么定义极其严格的、所有Skill都遵守的通用数据格式几乎不可能要么就得为每两个需要协同的Skill编写额外的“适配器逻辑”复杂度陡增。缺陷三“万能Agent”的幻觉与“职责蔓延”Skills市场给人一种错觉我可以打造一个“万能个人助理”。于是我们不断给Agent添加Skill它能订餐、能写代码、能做PPT、能回邮件……结果就是“职责蔓延”。这个Agent变得臃肿不堪其提示词Prompt里塞满了数十个Skill的描述导致LLM在决定使用哪个Skill时面临“选择困难症”响应速度变慢出错的概率也大大增加。它什么都懂一点但什么都不精且因为没有核心的“人格”或“专注领域”其行为表现是割裂和不稳定的。正是这些在实践中不断碰壁的经历让我意识到单纯增加Skills的数量是一条通往“智能”的歧路。我们需要的不是更多的工具而是一个更会使用工具的大脑。3. 重新定位Agent的核心是“心智架构”而非“技能仓库”那么什么才是AI Agent更本质、更正确的方向我的结论是重心必须从“技能中心化”转向“心智中心化”。我们需要构建的不是一个技能仓库而是一个具备高级认知能力的智能体架构。这个架构至少应包含以下几个核心层次3.1 层次一自主规划与任务分解能力这是强大心智的基石。一个真正的Agent应该能够理解一个模糊的、高层次的用户目标例如“提升我的网站流量”并自动将其分解为一系列具体的、可执行的任务序列。如何实现这需要超越简单的提示工程。我们可以采用Chain of Thought (CoT)和Tree of Thoughts (ToT)等高级推理框架。例如让Agent先输出一个思考过程“要提升网站流量我需要1. 分析当前流量来源GA4 Skill。2. 诊断内容短板内容审计Skill。3. 研究竞争对手关键词SEO工具Skill。4. 制定内容更新计划规划能力。5. 执行内容更新或外联内容发布Skill。”关键技术点这里的关键是让LLM具备“暂存”中间计划并迭代修正的能力。这通常需要外挂一个“规划模块”该模块维护一个任务栈Task Stack或状态机动态管理子任务的生成、执行、成功/失败状态以及回溯Backtracking。像AutoGPT、BabyAGI这类早期项目其核心探索的就是这种自主规划能力尽管它们在当时受限于模型能力而显得不稳定。3.2 层次二持续的记忆与学习机制记忆是形成“个体性”和“专业性”的关键。一个没有记忆的Agent每次对话都是“金鱼脑”无法进行深度的、上下文相关的协作。短期工作记忆用于存储当前复杂任务的上下文、中间结果和决策路径。这可以通过向量数据库高效实现将对话历史、工具执行结果等切片存储和检索。长期经验记忆让Agent能够从历史交互中学习。例如上次它用某种方式处理数据失败了这次遇到类似情况它能回忆起教训并尝试新策略。这涉及到更复杂的机制如将成功/失败案例存入知识库并通过检索增强生成RAG在需要时注入提示词。更进一步可以采用强化学习RL框架让Agent根据任务完成度获得奖励从而微调其策略模型可以是LLM本身也可以是一个小的决策网络。3.3 层次三动态的工具使用与创造能力这才是Skills应该存在的位置——作为心智可以随时调用的“工具库”。但调用方式不是被动的清单选择而是主动的、目标驱动的。工具的动态描述与发现Agent不应绑定一个固定的Skills清单。它应该能读取一个工具注册表理解每个工具的功能描述用自然语言或结构化Schema并在需要时动态决定是否使用、使用哪个。这类似于OpenAI的Function Calling机制但更上层。工具的创造与组合当现有工具都不完全匹配需求时高级的Agent应能尝试组合多个基础工具来创造新功能或者甚至能生成简单的代码如一个Python脚本作为一次性工具来解决问题。这就是所谓的“工具制造”能力是智能体灵活性的最高体现。3.4 层次四反思与自我修正循环这是区分普通自动化和真正智能的关键。一个强大的Agent在执行过程中应有“监控-评估-调整”的循环。监控在执行每个步骤后检查结果是否符合预期例如调用API是否返回了错误码分析结果是否回答了子问题。评估与反思如果结果不理想Agent需要能分析原因“是我用的工具不对是我提供的参数有误还是整个任务分解策略需要调整” 这个过程就是反思Reflection。调整与重试基于反思Agent调整策略可能选择不同的工具修改参数甚至回溯到上一步重新分解任务。这个循环使得Agent具备了强大的容错和自适应能力。将上述四个层次组合起来我们就得到了一个全新的Agent架构图景一个以“规划-记忆-反思”为核心心智以“动态工具库”为四肢的完整智能体。Skills在这个体系中并未消失而是被降维成了“工具库”中的可选项其重要性让位于心智的强度。4. 新范式下的实践构建以“心智”为核心的Agent理论需要实践来验证。下面我以一个具体的项目为例展示如何摒弃“Skills堆砌”思维从头构建一个以心智为核心的Agent。这个项目的目标是创建一个“智能研究助理”它能根据一个宽泛的研究主题如“量子计算对加密货币安全性的远期影响”自动进行多轮、多源的资料搜集、分析对比并最终生成一份结构化的研究报告。4.1 架构设计明确心智与工具的边界首先我放弃了寻找一个“万能研究Skill”的想法而是先设计智能体的心智流程。规划模块接收用户主题生成一个研究计划大纲。这本身就是一个LLM调用提示词要求它输出如“1. 定义关键术语2. 搜集学术观点正反3. 分析技术时间线4. 评估产业影响5. 总结并指出不确定性”这样的步骤。记忆中枢设立一个向量数据库我用的是ChromaDB用于存储所有中间产物研究计划、搜索到的网页摘要、提取的关键论点、生成的草稿片段等。每个记忆片段都带有元数据如所属任务步骤、来源、置信度。执行引擎与工具库这是唯一涉及“Skills”的地方。我准备了几个基础工具web_search(query): 调用SerpAPI进行网络搜索。fetch_and_summarize(url): 抓取网页内容并用LLM提取核心摘要。academic_search(query): 调用Semantic Scholar API查找论文。compare_arguments(argument_list): 用一个LLM调用对比多个观点的异同。write_section(topic, context): 根据主题和上下文撰写报告章节。反思控制器这是一个独立的LLM调用节点它的输入是当前任务步骤的目标和实际输出输出是对执行质量的评估“成功”、“部分成功需补充”、“失败需重试”以及下一步建议。整个系统的工作流不再是线性的而是一个由规划模块发起由反思控制器调节的循环网络。4.2 核心实现规划、执行与反思的循环我使用LangChain框架来编排这个流程因为它提供了良好的抽象来组合这些模块。以下是简化后的核心逻辑伪代码# 伪代码展示心智循环 from langchain.vectorstores import Chroma from langchain.llms import OpenAI from langchain.agents import Tool # 初始化组件 llm OpenAI(temperature0) # 用于规划和反思的“大脑” vectorstore Chroma(...) # 记忆中枢 tools [web_search_tool, summarize_tool, ...] # 工具库 def research_agent(topic): # 阶段1规划 plan_prompt f作为研究助理请为以下主题制定详细研究计划{topic}。输出一个步骤列表。 research_plan llm.invoke(plan_prompt) save_to_memory(plan, research_plan, vectorstore) steps parse_plan(research_plan) # 解析出步骤列表 for step in steps: max_retries 3 for attempt in range(max_retries): # 阶段2执行当前步骤 # 从记忆中检索相关上下文 context retrieve_from_memory(step, vectorstore) # 决定使用哪个工具或直接由LLM推理 action, action_input decide_action(step, context, tools, llm) result execute_action(action, action_input) # 调用工具或LLM # 阶段3反思与评估 reflection_prompt f步骤目标{step}。执行结果{result}。请评估(a)结果是否充分满足目标(b)如果不缺失什么(c)下一步建议继续、重试此步、或调整计划 reflection llm.invoke(reflection_prompt) save_to_memory(fstep_{step}_attempt_{attempt}, result, vectorstore) save_to_memory(freflection_{step}, reflection, vectorstore) if 充分 in reflection or 继续 in reflection: break # 当前步骤成功进入下一步 elif 重试 in reflection: continue # 重试当前步骤 elif 调整计划 in reflection: # 触发重新规划 steps replan(topic, vectorstore, llm) break # 阶段4综合与输出 final_context retrieve_all_relevant_memories(topic, vectorstore) report llm.invoke(f基于以下研究材料撰写一份完整报告{final_context}) return report在这个流程中decide_action函数是“心智”的关键。它不再是从一个清单里匹配Skill而是基于当前步骤的目标、历史上下文和可用工具的描述动态地决定是直接推理还是调用某个工具或是组合多个工具。这模仿了人类研究员的思考方式。4.3 避坑经验从Skills思维转换到心智思维的挑战在构建这个新范式Agent的过程中我遇到了不少挑战也积累了一些关键经验经验一设计“好”的规划与反思提示词是成败关键规划和反思模块完全依赖LLM其提示词设计至关重要。它们必须产出结构化、可解析的输出。规划提示词要明确要求输出编号步骤并最好能定义每个步骤的输入和期望输出类型。例如“步骤1定义关键术语。输出一个JSON对象包含术语和定义。”反思提示词要强制进行多维度评估。我使用的模板是“评估维度1. 完整性0-5分2. 相关性0-5分3. 建议继续/重试/调整。请以JSON格式输出。” 这比让LLM说一段模糊的评语可靠得多。经验二记忆的存储与检索需要精心设计把所有东西都扔进向量数据库然后做语义搜索效果会很差。分片存储将长文本如一篇论文摘要切成有意义的片段如“问题陈述”、“方法”、“结论”分别存储并打上统一的doc_id和chunk_type标签。混合检索检索时结合语义搜索找到相关内容和元数据过滤例如step2且doc_type‘web_summary’。这能确保Agent在需要时找到最相关且类型正确的记忆。记忆的“保鲜期”对于长期运行的任务需要考虑记忆的权重衰减。过于久远的、与当前步骤无关的记忆在检索时应降低优先级避免干扰。经验三工具描述需要兼具自然语言与精确性为了让LLM能正确选择和使用工具工具的描述description需要精心编写。它不能是简单的“搜索网络”而应该更像一份迷你说明书反面教材web_search: “一个用来搜索网络的工具。”正面教材web_search: “此工具接受一个搜索查询字符串作为输入返回最新的网页搜索结果列表。适用于查找实时信息、新闻、定义或广泛的主题概述。不适用于查找特定的学术论文或深度技术文档请使用academic_search。输入应为明确的关键词或问题。”经验四控制循环避免无限递归或成本失控自主Agent很容易陷入“反思-重试”的死循环或者因为规划过于细致而产生天价的API调用费用。设置硬性限制为每个步骤设置最大重试次数如3次为整个任务设置最大LLM调用次数或总预算。设计“投降”机制在反思环节加入“如果经过X次尝试仍无法解决建议暂停并请求人类协助”的选项。这比让Agent无意义地空转要明智得多。5. 未来展望Agent心智的进化与生态重塑基于“心智核心”的新范式我们可以展望AI Agent未来几个清晰的发展方向5.1 方向一专用化、深度化的垂直Agent“万能助理”的梦想可能不切实际但“超级专家”的价值是巨大的。未来的Agent生态将涌现出大量深耕某一垂直领域的Agent它们拥有针对该领域特化的心智模型和工具链。例如一个“法律合同审查Agent”它的核心心智是理解法律条款的逻辑结构、风险点和惯例。它的工具库不是通用的搜索和写作而是接入法律数据库、判例系统、特定条款风险评分模型。它的规划能力体现在对合同从头到尾的审查路径上它的记忆存储着大量同类合同的审查模式。这样的Agent其价值远高于一个只会调用通用“文本分析Skill”的杂家。5.2 方向二Agent间的协作与组织单个Agent的能力终有极限。复杂的现实任务可能需要多个各具专长的Agent组成一个“小组”或“虚拟公司”来协同完成。架构设想可以有一个“经理Agent”负责接收顶层任务、进行宏观规划并分解子任务然后将子任务分派给“研究员Agent”、“程序员Agent”、“设计师Agent”。这些Agent之间通过标准的消息协议进行通信共享工作记忆一个公共的向量数据库并由经理Agent协调进度、解决冲突。这涉及到多Agent系统MAS的研究如角色定义、通信语言、协商机制等。5.3 方向三从“工具使用者”到“世界模型构建者”这是更前沿的方向。目前的Agent主要通过API与数字世界交互。未来的Agent可能需要建立对物理世界或更复杂数字环境的“模型”。体现在Agent不仅能调用“控制机械臂”的Skill还能在心中或在其内部状态中对机械臂、工作环境、物体有一个简化的物理模型从而预测动作的结果进行更安全的规划。这需要将LLM的推理能力与传统的符号知识表示、物理仿真等技术结合。虽然遥远但这是实现更自主、更可靠智能的必经之路。5.4 对开发者的新要求这一范式的转变也对AI Agent开发者提出了新的能力要求系统架构能力从编写单个Skill或Prompt转变为设计包含规划、记忆、执行、反思循环的复杂系统架构。提示词工程升级为“心智编程”需要设计引导LLM进行有效规划、深度反思的提示词这比让LLM调用一个函数要复杂得多。传统软件工程能力回归Agent系统将越来越像传统的分布式系统需要处理状态管理、错误处理、并发控制、可观测性日志、监控等问题。Skills热潮是一次有益的启蒙它让我们看到了让LLM连接现实世界的巨大潜力。但它也像一剂猛药让我们一度沉迷于外延的扩展而忽略了内涵的深化。现在是时候回归本质了。AI Agent的未来不在于给你的智能体装上多少把瑞士军刀而在于培养它一个善于观察、思考、计划和学习的大脑。这个大脑知道在何时、为何、以及如何拿起最合适的那把刀。这条路更艰难也更接近我们心目中“智能”的样子。