AI Agent构建：从技能堆砌到核心推理架构的实践反思

1. 从“技能”狂欢到“智能”回归：一个AI Agent实践者的反思

去年，整个AI圈几乎被“Skills”这个词刷屏了。无论是GitHub上雨后春笋般冒出的各种“Awesome-AI-Agent-Skills”列表，还是各路教程里手把手教你“如何为你的Agent添加10个必备Skills”，都营造出一种错觉：仿佛只要给大语言模型（LLM）套上一个能调用搜索引擎、能读写文件、能发邮件的“技能”外壳，一个智能体（Agent）就诞生了。一时间，“Skill”成了衡量Agent能力的核心指标，甚至出现了“Skill商店”的概念，颇有些当年手机应用商店刚兴起时的味道。作为一个从早期LangChain玩起，一路跟进AutoGPT、BabyAGI，再到深度参与过几个企业级Agent项目落地的从业者，我也曾沉浸在这种“技能堆砌”的兴奋中。但热潮退去，当我们在真实业务场景中试图用这些“超级技能”的Agent去解决一个具体的、模糊的、动态的问题时，却发现它们常常表现得像个“无所不能的傻瓜”——每个单一技能都执行得精准无误，但组合起来的决策逻辑却混乱不堪，无法形成有效的目标导向行为。

这促使我停下来重新思考：我们到底需要什么样的AI Agent？当“Skills”的热度逐渐冷却，我们更应该关注什么？我的结论是，方向错了。过去一年，我们过度聚焦于“臂”（Skills，即行动能力）的扩展，而严重忽视了“脑”（Core Reasoning，即核心推理与决策）的锤炼。一个真正有价值的AI Agent，其核心不在于它“会”多少事，而在于它“知道”在何种情境下“该做”何事，以及“如何”协调这些事来完成一个更高层次的目标。这就像评价一个项目经理，不是看他会不会用Excel、PPT、Jira（这些是Skills），而是看他如何理解项目目标、拆解任务、评估风险、协调资源（这是核心智能）。本文将结合我近期的实践与反思，抛开浮于表面的技能列表，深入探讨AI Agent构建中那些更本质、更艰难，但也更决定成败的方向。

2. “Skills”热潮的局限：为什么“万能工具箱”不是智能体

Skills架构的兴起有其必然性。它极大地降低了AI应用开发的门槛，将复杂的模型能力封装成一个个可调用的函数（Function Calling），让开发者可以像搭积木一样快速组合出功能。常见的Skills包括：网络搜索（SerpAPI）、代码执行（Code Interpreter）、文件读写、数据库查询、发送邮件、调用第三方API等等。在Harness、LangChain、LlamaIndex等框架的推波助澜下，这种模式迅速流行。

然而，在实际复杂场景中，这种模式的短板暴露无遗。最核心的问题是：技能的执行缺乏有效的、上下文感知的调度与协同逻辑。大多数基于Skills的Agent，其核心调度逻辑可以简化为一个循环：LLM根据当前目标和上下文，从技能列表中选择一个来调用，等待结果，更新上下文，然后继续选择下一个技能。这个模式存在几个致命伤：

2.1 技能选择的脆弱性

LLM在众多技能中做选择，本质上是一个基于自然语言描述的文本分类问题。当技能数量增多、功能描述相似或场景复杂时，LLM极易“选错”。例如，一个Agent同时拥有“从数据库查询用户信息”和“从CRM系统API获取用户资料”两个技能。当用户提问“告诉我张三的客户等级”时，LLM可能随机选择一个，而开发者很难通过提示词（Prompt）百分之百地保证它每次都能选择更准确、更实时的数据源。这种不确定性在严肃的业务系统中是不可接受的。

2.2 无法处理技能间的依赖与副作用

真实任务往往是多步骤且有状态的。技能A的输出，可能是技能B的输入。技能C的执行，可能会改变系统状态，从而影响技能D的可行性。简单的“选择-执行”循环无法显式地建模这种依赖关系和状态变迁。例如，一个“数据报告生成Agent”可能需要：1. 从数据库拉取原始数据；2. 调用Python技能进行数据清洗；3. 将清洗后的数据写入临时文件；4. 调用图表生成技能读取文件并制图。如果步骤3失败，步骤4必然失败。而基础的Agent循环可能在步骤3失败后，依然试图执行步骤4，或者陷入“重试步骤3”的死循环，因为它缺乏一个全局的任务计划图来理解步骤间的因果关系。

2.3 目标漂移与无效循环

在没有强目标管理和反思机制的情况下，Agent容易在执行中“跑偏”或陷入局部操作。经典的例子是早期AutoGPT经常发生的“为了研究一个话题，不断给自己新建文本文档并写入内容，最终产生成千上万个文件却未产出任何有价值摘要”的情况。这就是技能（读写文件）脱离了高层目标（研究并总结）的约束，导致了资源浪费和任务失败。Skills提供了“做什么”的能力，但没有解决“为什么做”和“做到什么程度为止”的问题。

因此，将AI Agent等同于“LLM + Skills工具箱”是一种严重的误解。Skills是必要的“四肢”，但让四肢协调工作、朝着正确方向前进的“大脑”和“小脑”（规划与控制系统）才是智能体的灵魂。热潮过去后，我们的注意力必须从“收集更多技能”转向“构建更强大、更鲁棒的核心推理与控制系统”。

3. 超越Skills：AI Agent的核心架构再认识

要构建真正有用的Agent，我们需要一个更完整的架构视角。参考学术界和工业界的实践，一个成熟的AI Agent系统通常包含以下核心层级，我们可以将其类比为一个完整的“人”：

3.1 感知层（Perception）这是Agent与世界的接口，远不止于“用户输入文本”。它包括：

• 环境状态感知：读取数据库、监控系统日志、解析API返回的JSON、理解图像或语音输入。Skills中的“读取文件”、“查询数据库”可以看作感知层的一部分。
• 信息结构化：将非结构化的感知信息（如一段文本、一张图表）转化为Agent内部可以理解和推理的结构化表示。这常常需要借助RAG（检索增强生成）技术，从知识库中检索相关背景信息，与当前感知融合。

3.2 认知与推理层（Cognition & Reasoning）这是Agent的“大脑”，是最核心、最困难的部分。它负责：

• 目标理解与分解：将模糊的用户指令或高层目标（如“优化网站性能”）解析并分解为一系列具体的、可操作的任务（如“分析加载速度”、“识别大图文件”、“建议压缩方案”）。
• 规划与决策：基于当前状态、历史经验和任务目标，生成一个行动计划（Plan）。这个计划需要明确步骤、步骤间的依赖关系、预期的结果和备选方案。这超越了简单的“下一个技能选哪个”，而是生成一个完整的任务流程图。
• 反思与评估：在执行过程中或阶段结束后，评估当前结果与目标的差距，判断计划是否有效，是否需要调整策略。例如，在执行“数据清洗”技能后，检查数据质量是否达到下一步“分析”的要求，如果未达到，是重试清洗还是尝试另一种清洗方法？

3.3 技能与执行层（Skills & Execution）这就是我们熟悉的Skills层，是Agent的“四肢”。但在此架构下，它的角色更清晰：纯粹、可靠地执行来自认知层下达的具体指令。一个设计良好的技能应该是：

• 功能单一且健壮：做好一件事，并有完善的错误处理。
• 接口明确：输入、输出格式标准化、结构化。
• 可预测：在相同输入下，输出应该一致。

3.4 记忆与状态管理层（Memory & State）这是Agent的“经历与工作台”，负责：

• 短期工作记忆：存储当前任务链的上下文、中间结果、执行状态。
• 长期经验记忆：存储历史任务的成功/失败模式，用于未来决策的参考（即基于经验的学习）。
• 世界模型状态：维护Agent对当前环境状态的内部信念（Belief），这个信念会随着感知和行动的结果而更新。

在这个架构中，Harness这类基础设施，正如热词中提到的，它是一套包裹在AI Agent核心推理逻辑之外的基础设施层。它不代替Agent做决策，而是为上述所有层级提供支撑，比如：为技能调用提供安全沙箱、统一管理API密钥、处理并发请求、提供可观测性（日志、追踪）等。它让开发者能更专注于核心推理逻辑（大脑）的建设，而不是重复造轮子（工具管理、安全、部署）。

因此，构建Agent的重点，应该从“寻找和封装更多技能”（加强四肢），转向“设计和实现更强大的认知与推理层”（锻造大脑）。大脑的强弱，直接决定了四肢的力量能否被有效发挥。

4. 锻造“大脑”：核心推理与规划能力的实现路径

既然认知层是关键，我们该如何着手构建？以下是我在实践中总结出的几个渐进式路径，它们并非互斥，而是可以叠加使用。

4.1 从提示工程到规划框架（Prompt Engineering -> Planning Frameworks）

最初的规划能力完全依赖LLM通过提示词来“零样本”生成步骤列表。这种方式简单但脆弱。下一步是引入规划框架，例如：

• Chain of Thought (CoT) & Tree of Thoughts (ToT)：强制LLM展示其推理步骤，或并行探索多种推理路径，选择最优。
• ReAct (Reasoning + Acting)模式：将“思考”和“行动”步骤明确分离并循环。Agent在每次行动前，都必须先生成一段“思考”（Thought），解释为什么要采取这个行动，期望得到什么结果。这虽然增加了开销，但极大地提升了决策的可解释性和可控性。在代码实现上，这通常体现为一个固定的循环结构：

  # 简化的ReAct循环伪代码 while not task_is_complete(goal, state): # 1. 思考 thought = llm.generate(f”基于目标{goal}和当前状态{state}，我应该做什么？为什么？”) # 2. 行动 action = llm.generate(f”根据思考‘{thought}’，选择一个技能并生成调用参数。”) result = execute_skill(action) # 3. 观察 state.update(thought, action, result)

• 计划生成与校验：让LLM先生成一个完整的、分步骤的计划，然后由一个简单的校验器（可以是规则，也可以是另一个LLM）检查计划的合理性和可行性，再开始执行。这避免了“边想边做”导致的路径错误。

4.2 引入外部规划器与状态机

对于复杂、流程固定的任务，完全依赖LLM做规划成本高且不稳定。此时，可以引入外部规划器。

• 基于工作流引擎：对于客服、审批、数据ETL等场景，可以将常见的任务流程预定义为工作流（如使用Apache Airflow、 Temporal 或 Camunda）。Agent的“大脑”在这里简化为一个“工作流选择器”和“节点执行器”。LLM负责根据用户输入选择正确的工作流模板，并在执行每个节点时处理非结构化的输入输出。这结合了规则的确定性和LLM的灵活性。
• 基于状态机（State Machine）：将Agent的任务生命周期明确定义为几个状态（如：空闲、分析需求、规划中、执行步骤1、等待用户输入、执行完成）。状态之间的转移由事件（如“用户确认”、“步骤执行成功/失败”）触发，而转移条件或触发的动作可以由LLM参与判断。这使Agent的行为更可控、更易调试。

4.3 构建领域特定的世界模型与评估函数

这是实现高级自治的关键。Agent需要对它所处的环境有一个“模型”，并知道如何评估好坏。

• 世界模型：让Agent学习其行动如何影响环境状态。在一个代码生成Agent中，世界模型可以是一个简单的“代码是否通过编译/测试”的反馈。在一个游戏Agent中，世界模型可能是对游戏画面和分数变化的预测。我们可以通过让Agent在模拟环境中试错（强化学习）或从历史数据中学习（监督学习）来构建简单的世界模型。
• 评估函数（Reward Function）：定义什么是“好”的结果。对于摘要任务，评估函数可以是ROUGE分数；对于代码任务，可以是测试用例通过率；对于对话任务，可以是用户满意度。在规划时，Agent可以模拟不同行动序列的预期结果（利用世界模型），并选择评估分数最高的路径。这赋予了Agent前瞻性和优化能力。

4.4 实现持续反思与元认知

一个智能体应该能从错误中学习。这需要反思循环。

1. 行动后反思：在每个主要步骤或任务结束后，强制Agent写一份简短的“事后报告”：目标达成了吗？哪里出错了？如果重来，会有什么不同？
2. 经验库存储：将这些反思（成功或失败的模式）以结构化的方式存储到长期记忆中。
3. 未来决策参考：当遇到类似场景时，从经验库中检索相关案例，作为上下文提供给LLM，提示它避免重蹈覆辙或复用成功策略。

这个过程将一次性的任务执行，变成了一个持续学习和改进的系统。例如，一个数据清洗Agent第一次用某种方法处理某类脏数据失败了，经过反思，它将“某类数据+某方法=失败”这个模式记下来。下次遇到类似数据，它就会主动尝试其他方法。

5. 实战重构：以“Zabbix故障自愈Agent”为例

让我们用一个热词中提到的具体场景来串联以上理念：Zabbix接入AI Agent实现自动处理故障。如果按照旧的“Skills”思路，我们可能会这样做：给Agent装备“查询Zabbix API”、“执行SSH命令”、“重启服务”、“发送告警”等技能，然后写一个提示词：“请分析Zabbix告警并尝试修复”。

可以预见，这个Agent会非常不可靠。它可能一看到“CPU负载高”的告警，就直接去重启服务器，而不先检查是否是正常业务高峰；它可能尝试用错误的命令去重启一个不存在的服务。

现在，我们用新的架构思维来重新设计这个Agent：

5.1 定义清晰的认知架构

• 感知层：定期调用Zabbix API获取TRIGGER_STATUS=‘PROBLEM’的告警列表。将每条告警的hostname,trigger name,severity,item key,latest value等信息结构化。
• 认知与推理层：
  • 目标理解：核心目标是“消除告警，恢复服务”，子目标包括“准确诊断根因”、“执行最小化修复动作”、“避免影响业务”。
  • 规划器：我们实现一个基于诊断树的规划器。这不是一个通用的LLM规划器，而是一个针对运维领域的专用规划器。它内部维护一个“故障现象-诊断动作”的映射库。
    • 输入：结构化的告警信息。
    • 过程：LLM或规则引擎将告警分类（如：属于“数据库”、“网络”、“应用服务”）。根据分类，选择对应的诊断流程脚本。
    • 输出：一个具体的诊断计划，例如：[“通过SSH登录主机A，检查进程列表”， “如果进程存在，检查日志文件/var/log/app/error.log”， “如果日志中有OOM错误，检查内存使用情况”…]。
• 技能层：
  • execute_ssh_command(host, command)
  • parse_log_file(log_path, pattern)
  • check_disk_usage(host)
  • restart_service(host, service_name)
  • rollback_config(host, config_file)
  • notify_team(alert_info, action_taken)
• 记忆与状态层：
  • 记录每一条告警的处理状态（待处理、诊断中、修复中、已解决、需人工介入）。
  • 记录所有执行过的命令及其结果。
  • 维护一个“操作回滚栈”，以便修复失败时能快速恢复。

5.2 实现核心推理循环这个Agent的核心循环不再是“选技能”，而是“执行诊断计划”：

1. 感知：获取新告警。 2. 认知（诊断分类）：LLM/规则判断告警类型 -> 选择诊断树。 3. 规划：生成基于诊断树的具体检查步骤序列。 4. 循环执行步骤： a. 思考：为什么要执行这一步？（例如：“检查磁盘空间，因为告警是‘磁盘写满’，这是最可能的原因。”） b. 行动：调用对应技能（如`check_disk_usage`）。 c. 观察：获取结果（如“磁盘使用率95%”）。 d. 评估：结果是否指向根因？（是，进入修复阶段；否，进入诊断树下一个节点）。 5. 修复规划：根据确定的根因，生成修复计划（如“清理/var/log下旧日志文件”）。此计划应包括预检查（“是否有重要日志？”）和回滚方案（“备份要删除的文件”）。 6. 执行修复与验证：执行修复动作，然后再次运行诊断检查，确认告警是否消除。 7. 反思与记录：将本次告警的现象、诊断过程、根因、修复动作、结果完整记录到知识库。如果是一个新出现的故障模式，可以提示工程师将其更新到诊断树中。

5.3 关键设计要点与避坑经验

• 安全边界是第一位：任何修复动作的执行，都必须经过“模拟执行”或“人工确认”阶段，尤其是重启、删除、修改配置等高风险操作。初期可以设置为Agent只诊断、不修复，修复建议通过通知技能发送给运维人员。
• 技能必须幂等且可回滚：restart_service技能应该先检查服务状态，如果已停止则启动，如果已在运行则无害。rollback_config技能必须能可靠地将配置恢复到之前版本。
• LLM用于理解与分类，而非直接生成命令：不要让LLM直接生成rm -rf这样的Shell命令。应该让LLM输出结构化的意图，如{“action”: “clean_old_files”, “target_dir”: “/var/log”, “retention_days”: 7}，然后由安全的、经过审核的代码来执行具体的命令生成。
• 构建运维知识库：将成功的诊断修复案例作为向量存入知识库（RAG）。当新告警出现时，先进行相似案例检索，这能极大提升诊断速度和准确性。这就是“长期记忆”的应用。

通过这样的设计，这个Zabbix Agent不再是一个拥有“重启”、“查日志”等技能的简单工具，而是一个具备初步故障诊断、规划、执行和反思能力的“初级运维工程师”。它的价值不在于技能多炫酷，而在于其处理不确定性问题、遵循安全流程、积累经验的核心推理能力。

6. 开发者如何转向：技术栈与能力重塑

如果你是一名开发者，希望从“Skills集成者”转向“Agent架构师”，你需要有意识地构建以下技术栈和能力：

6.1 技术栈的深化与拓宽

• 编程语言：Python依然是绝对主流（生态丰富），但Java（Spring AI）和C#也有相应框架。选择取决于你的团队和业务环境。重点不是语言，而是对异步编程、事件驱动、状态管理的深刻理解，因为Agent本质上是事件驱动的状态机。
• 核心框架：
  • LangChain/LlamaIndex：仍是快速原型和构建RAG的强大工具，但不要局限于其Agent模块。深入理解其Chain、Memory、Callback机制，用于构建自定义的推理流程。
  • 专有Agent框架：关注像AutoGen（微软）、CrewAI这类更强调多Agent协作和规划能力的框架。它们提供了更高级的抽象来处理角色分配、任务分解和协同。
  • 工作流引擎：学习一两个如Prefect、Airflow或Temporal，理解如何将确定性的业务流程与LLM的不确定性推理结合起来。
• 基础设施：了解Harness、BentoML、Ray等模型部署和服务的概念，理解如何管理技能服务的生命周期、监控和扩缩容。

6.2 核心能力的重塑

• 从提示词工程到“系统提示词”设计：不再只关注让LLM回答好一个问题，而是设计一套完整的“系统指令”，定义Agent的角色、目标、约束、输出格式和思维框架（如“你必须以ReAct格式思考”）。
• 从函数封装到“技能API”设计：设计技能时，思考其输入/输出的标准化、错误码体系、幂等性、安全性。将其视为一个微服务来设计API契约。
• 从脚本编写到“状态机与规划器”开发：学习用代码清晰地定义Agent的状态、事件和转移逻辑。尝试实现简单的规划算法，如基于图的规划或HTN（分层任务网络）。
• 掌握可观测性（Observability）：Agent系统黑盒程度高，必须建立强大的日志、追踪（Tracing）和评估体系。记录每一个LLM调用（输入/输出）、每一个技能执行、每一个状态变更。这是调试和优化的生命线。

6.3 思维模式的转变最重要的是思维模式的升级：从“如何让LLM调用工具”转变为“如何设计一个能自主解决问题的智能系统”。你需要思考：

• 这个Agent的核心目标是什么？（不是功能列表）
• 它如何感知环境？状态如何表示和更新？
• 面对不确定性，它有哪些决策机制？（规则、LLM、规划器、投票？）
• 它如何评估自己的进展和成功？反馈回路是什么？
• 它如何从经验中学习？知识如何沉淀和复用？

Skills热潮是一堂生动的启蒙课，它让我们看到了AI应用的巨大潜力。但热潮褪去，留下的才是真正需要深耕的领域。AI Agent的未来，不在于拥有一个无所不能的“技能百宝箱”，而在于拥有一个在特定领域内能够审时度势、规划路径、从错误中学习并稳健执行的“大脑”。这条路更艰难，也更值得探索。作为开发者，我们的任务不再是简单地连接API，而是开始学习如何为机器注入一点真正的“智能”。