• 简介
• 分阶段
  • 简单使用LLM 是不够的
  • workflow与agent
  • agent 1.0 ==>agent 2.0
• 原理
  • 认知框架Cognitive Architecture
  • stop token
• 代码解释器
• Claude Skills
  • 是什么
  • 发现与加载（未完成）
  • 一些实践
• 大佬

简介

吴恩达：目前，我们使用大语言模型的主要方式是一种non-agentic工作流程，即您输入一个提示,模型就生成一个回答。这有点像让一个人坐下来一次性从头到尾编写一篇文章，而不允许使用退格键,尽管这样做很难，但大语言模型的表现出奇地出色。相比之下，代理工作流程看起来是这样的: 首先，让人工智能大语言模型写一个文章大纲，如果需要进行网络研究就先做研究，然后写出第一稿,然后阅读并思考需要修订的部分，再修改这一稿，如此循环往复、迭代多次。很多人没有意识到,这种做法可以带来显著的改进效果。我自己在使用这些代理工作流程时也感到非常惊讶，它们工作得如此之好。研究发现，GPT-3.5使用零样本提示时只有48%的正确率，GPT-4提高到了67%。但如果在GPT-3.5上使用一个代理工作流程，它的表现实际上比GPT-4还要好。如果在GPT-4上使用代理工作流程，它的表现也非常出色。这意味着采用代理工作流程对于构建应用程序至关重要。不过我们需要改变一种习惯，那就是习惯了在提示语言模型后立即获得响应。在代理工作流程中，我们需要学会能够耐心等待几分钟甚至几个小时，才能得到响应，就像我们交代任务给人时需要适当地等待一段时间再进行检查一样。

分阶段

智能体的几种范式

1. 简单llm
2. workflow
3. Agent。PS：适用啥还是看场景。
   1. ReAct，模拟了人类“边做边想”的认知过程，但在长程任务易失控：当步骤超过 10 步时，错误会逐级放大，且难以回溯修正。对于流程固定的复杂任务（如数据清洗流水线），重复推理造成大量冗余 LLM 调用，推高延迟与成本。
   2. Planner：面对 ReAct 的“短视”问题，研究者转向规划先行（Plan-then-Execute）范式。缺点，一旦环境突变（如某 API 下线），整个计划可能失效，需额外设计“重规划”（re-planning）机制。
4. Multi-Agent
   1. 集中式调度
   2. 协作式涌现，适用于边界模糊、需多视角融合的复杂场景。

简单使用LLM 是不够的

纯问答的场景只是大模型落地的第一步，还有许许多多场景是需要AI大模型与现实世界进行“连接”才能完成的。我们并不需要一个只知道聊天的机器人“玩具”，我们需要的正是这种“有手有脚”的大模型、能做事情的大模型。比如客户的问题是“退款”，那么客户想要执行退款这个操作，而不是大模型提供一堆退款的规则和步骤，因为绝大多数的人对于很长的文字是很难完全有耐心能阅读下去的。试想一下，当你躺在家里的床上准备睡觉的时候，突然发现窗帘没有关上，如果这时候跟大模型说“请帮我关闭我家的窗帘”，其实我们并不想听到大模型回复了一大段的“关闭窗帘的步骤”，如果大模型真的像一个人一样能够完成这件事情，那该有多酷！甚至当你说出一些稍微复杂指令，比如“窗帘不用全部关上，给我留一个缝”，如果大模型也能“理解”并且能自动将“留一个缝”这种自然语言转换为控制“窗帘闭合百分比”这样的一个量化参数并且真正将窗帘关闭到合适位置的时候，那么大模型才真正能在各行各业的落地中带来一波大的浪潮。

目前的大模型一般都存在知识过时、逻辑计算能力低等问题，通过Agent访问工具，可以去解决这些问题。Agent是指能够感知环境、做出决策和采取行动的实体。本质上还是prompt工程，通过Prompt去驱动模型进行 计划和工具调用。PS：你知道一个工具的存在，约等于你会调用这个工具；你会调用这个工具，约等于你会学习使用这个工具；会学习这个工具，约等于你已经会用这个工具；所以，你知道工具的存在，约等于你能把这件事做出来。搜索高于学习， 学习高于熟练。

workflow与agent

2025年认为的Agent： 25年什么样的 Agent 会脱颖而出：简单胜于复杂Anthropic 把下述两种统称为 agentic systems：

1. Workflows: 通过预定义代码路径协调LLMs和Tools。
2. Agents: LLM自主决定过程和Tools的使用，控制任务完成方式。一般来说是由agent loop驱动的一种专门的AI系统。在每一个循环迭代中，它借助LLM动态决策，自动调用适当的工具，存取恰当的记忆。每经过一次循环，就向着任务目标前进一步。

Agent的定义是随着大模型的发展而变化的；从人类编排任务流程到人类描述详细任务细节到人类发出简单指令，AI在其中扮演的规划、执行角色从少到多，Agent也在不同阶段有不同的定义。但是上述不同阶段会长久地并存，就像Python的出世，并不会影响到C/C++/Java的消亡，因为物理世界是复杂的，大家可以在不同领域发光发热。

Agent的构建分为不同复杂度级别，从基础的增强型大语言模型Augmented LLM开始，逐步发展到预定义的workflow，最终形成自主的 agent。

1. 增强型大语言模型(augmented LLM)是Agent的基本构建单元，它集成了检索、工具和记忆等能力。现代模型能够主动使用这些功能，如生成搜索查询和选择适当工具。PS：比如让llm 输出struct，很多框架都提供llm.structured_predict
2. 对于可预测、定义明确的任务，需要一致性时使用workflows；比如某些开源的 Deep Research 项目中，有几种复现方式
   1. 将用户问题分解为多个子查询，每个子查询由不同模型或模块处理，最后由一个模型统一整合答案。
   2. 模型先给出初步回答，然后自我评价打分，假如评价不 ok，就循环修改，直到达到满意结果，类似于毕业论文的修改过程。
3. 相比于 workflow，Agent 的设计反而是很简单。背后依靠强大的推理模型，让模型自己去理解复杂输入、进行推理和规划、使用工具以及从错误中恢复。Agent在循环(loop)中工作，根据输入自己选择合适的工具，并能根据环境反馈调整策略——例如当代码执行失败时，能根据错误信息自动修正；智能体的核心在于模型主导全部决策过程（模型能够在 in a loop 中自主处理问题，无须人为定制某个step+prompt干预），人类无需预先定义详细流程，只需在特定情况下提供少量干预，如在Deep Research中我们只需要确认关键的信息或在Operator中当输入账号密码等敏感信息需要人类干预。本质上，agent将复杂任务的规划和执行权交给模型，所谓模型即服务，采用端到端的优化来提升效果。顶级的 Agent 可能工程代码及其简洁，这种简洁的背后，是超高质量的训练数据+极致的端到端强化训练。所有 if-else 和 workflow 的选择将由模型自身判断完成，而非依赖人工编写的规则代码。
   1. 只要“问题不可完全穷举、要跨多系统查证、并且需要在对话中澄清/协商/决策”，就更应该用 Agent 框架，而不是纯 Workflow。很多步骤无法事先“画”成固定分支，需要在对话上下文里做决策、需要跨工具动态组合、需要“问一句 → 查一下 → 再决定”，这正是 Agent 的强项。 做 LLM 项目最重要的不是构建最复杂的系统，而是为你的需求找到最合适的解决方案，建议从简单提示开始，只在必要时才引入复杂的智能体系统。

对于应用型算法工程师的启发

1. 积累场景测试集，持续测试新的模型。
2. 学会微调，积累微调insight。 要取得好的效果还是需要微调。无论是SFT还是RL，日常阅读论文时，要重点关注论文中数据的构建和实验思路。虽然现在有如llama_factory、openrlhf等微调框架，让微调变得简单，但工程师更重要的是积累微调的insight。例如，何时需要微调，何时通过改prompt即可解决问题；如何构建高质量数据集，怎么让业务同事也心甘情愿帮你标数据，多少数据能达到什么效果；何时使用SFT，何时使用RL。这些除了通过阅读论文获取一些方向思路外，更重要的是在自己的业务场景中多尝试。
3. 工程实践中避免过度设计。遇到新场景时，优先考虑“做减法”，而非“加积木”。例如，你开发了一个算法应用，一段时间后产品经理提出需要处理一个边缘情况，此时你不应优先考虑叠加新的处理模型或增加模型，而是：查看新出的模型是否能解决该情况，并简化之前的流程。这对应第一点，积累场景测试集，持续测试新的模型；基于对业务和数据的理解，尝试通过高质量业务数据+微调的方式解决问题，甚至合并之前的流程。这对应第二点，学会微调，积累微调经验。
4. 选择与大模型协同发展的方向。尽可能选择那些随着大模型的升级，应用效果会变得更好的解决方案，而不是做那些更强大的模型出来后之前的努力就白费的解决方案。
5. 对于能够快速通过workflow达到交付要求的场景，直接使用工作流即可。所以工程师还是需掌握各类框架，以快速灵活应对不同需求。但如果是一个长期需要不断优化的应用，那么请考虑一下采用端到端优化的形式。

我亲手开发的一个AI框架Bridgic，谈下背后的思考我们在设计系统底层的时候，就需要一套统一的概念，对这个可能具有不同自主程度的Agentic System进行统一的描述。只有这样，才能把各种不同的智能组件纳入到一个系统里面来无缝工作。在这里，系统是否建立在一套统一的概念基础之上，就是一个很重要的设计决策，也是一个涉及到第一性的问题。有些同学可能知道，在很多早期的智能体项目中，或者只具备描述workflow的能力，或者只具备描述agent的能力，或者干脆用两套不同的概念对两者进行各自的描述。这样提供出来的方案就是充满了割裂和违和感的，日后也很难扩展。在Bridgic的最底层，我们把智能体世界的万事万物都归结到两个核心概念之上。一个叫worker，一个叫automa。有了这两个概念，我们才能有进一步的讨论。

1. Worker是最基本的执行单元。落实到实际系统当中，它可能代表了一段精确执行的逻辑（比如一个function，或一个API调用），也可能是具备高度自主性的模块或系统，或者是一个可调用的工具。换句话说，任何一个实体，只要它有能力take action，不管它的自主性程度如何，都能使用worker这个概念来描述。
2. Automa是用来管理、编排和调度多个worker的那个实体。它是一个执行容器，自身不会直接处理任务，而是通过驱动它所管理的那些worker的执行，来完成更高层面的一个任务。落实到实际系统中，一个workflow，或者一个agent，或者任何的一个agentic system，都可以用一个automa来描述。

接下来就引出了另一个重要的问题：automa驱动worker执行的顺序，是怎么决定的？在一个确定性的workflow中，执行次序很可能是预先定义好的 (predefined) ；而在一个高度自主的agent中，每一步的执行次序很可能是模型动态规划出来的。这就涉及到了第二个核心的设计决策：automa对于worker的执行次序的编排，底层应该用什么方式来承载？AI Agent的自主性对于编排这件事有什么本质上的、不同的要求，它的能力边界应该划定在什么地方。各种不同的Agentic System，它们所呈现出来的不同程度的自主性，本质在于系统编排的执行路径是在何时决策的。总共分成了三种编排时机：

1. 静态编排（图纸式执行）：执行路径的每一步都是提前确定好的。一般使用DAG (Directed Acyclic Graph) 表达。
2. 程序动态编排（锦囊式应对）：具体执行时的路径只能根据输入数据动态确定。一般使用DG (Directed Graph)表达（有环？）。
3. 自主编排（LLM带来的自主性）：没法提前设想所有的可能情况，执行路径也需要根据执行动态现场确定。
   1. 模型的动态任务拆分，模型把一个复杂的任务拆成若干个子任务，子任务的数量以及每个子任务是什么，你都无法在编码的那一刻完全确定。也就是说，我们没法提前确定需要创建几个worker实例来运行这些子任务。
   2. 工具的动态选用，在一个agent loop中，每次模型都会选择若干个工具来执行。这个时候你也无法提前确定每次调用工具的数量，以及哪些工具会被调用。我们如果底层统一用worker这个概念来表达工具的话，那么worker的创建也需要是动态的。
   3. 我们增加一个时间维度，随着时间的流逝，允许图的拓扑在一定的限定条件下发生变化。这样我们就得到了一幅动态的图景，称之为动态有向图 (Dynamic Directed Graph) ，简称为DDG。Bridgic就是将底层构建在DDG之上的，允许一边执行一边修改图的拓扑。这一特性被称为动态拓扑 (Dynamic Topology)。Bridgic将编排方式统一于DDG之上，得以同时支撑各种不同程度的自主性（以及未来更高智能程度的自主性）。

用Agentic Loop有很多理由，用Workflow只有一个理由，因为要务实，要解决问题。

agent 1.0 ==>agent 2.0

LLM->Agent之间的距离就是构建Agent的工作量，随着技术的演进，系统封装的占比越来越大，人工定义的占比越来越小

1. 原始开发期。构建Agent需要完全依赖LLM暴露出来的openapi接口。
2. 脚手架时代。出现了LangChain脚手架，抽象了使用LLM的常用模型，Memory、Prompt、Tool等。
3. 低代码阶段。出现了封装Agent+中间件的平台，低代码的配置能力，减少工程成本。
4. 领域范式期。出现某些领域的“agent”模版，可以在替换部分tool之后，快速落地。

从浅循环到深度 Agent之前构建一个 AI Agent 通常意味着：设置一个 while 循环，获取用户提示，将其发送给 LLM，解析工具调用，执行该工具，将结果返回，然后重复。这就是我们所称的浅 Agent（Shallow Agent）或 Agent 1.0。这种架构在处理“今天的天气如何，我该穿什么？”这类事务性任务时极其简单有效，但当被要求执行一个需要三天内完成 50 个步骤的任务时，它们往往会分心、丢失上下文、陷入无限循环，甚至因步骤太多超出单次上下文窗口容量而出现幻觉。现在正在进行架构上的转变——迈向深度 Agent（Deep Agents），亦称 Agents 2.0。这些系统不再仅在循环中被动反应，而是结合 agentic 模式 来进行规划，管理 持久化记忆/状态（persistent memory/state），并将工作委派给专门的子 Agent（sub-agents），以解决多步骤、复杂的问题。

Agent1.0 的整个“头脑”都在上下文窗口内。当任务变得复杂，例如“调研 10 个竞争对手、分析定价模型、制作对比表格，并撰写战略总结”时，会因以下原因失败：

1. 上下文溢出： 历史记录被工具输出（HTML、混乱数据）填满，导致指令被挤出上下文窗口。
2. 目标丢失： 在中间步骤的噪声中，Agent 忘记最初的目标。
3. 无恢复机制： 一旦陷入死胡同，Agent 很少具备停止、回溯并尝试新方法的前瞻性。

深度 Agent 将规划与执行解耦，并在上下文窗口之外管理记忆。其架构由四大支柱组成。PS：以agent2.0 视角看，agent 1.0 一个llm+prompt干了所有这些活儿

1. 显式规划，深度 Agent 则使用工具来创建并维护显式计划，例如存放于 Markdown 文档中的待办清单。在每个步骤之间，Agent 会审查并更新该计划，将步骤标记为 pending、in_progress 或 completed，并可添加注释。如果某个步骤失败，它不会盲目重试，而是调整计划以适应失败，从而始终聚焦于整体目标。
2. 分层委派（Sub-Agents）。浅 Agent 试图在单一提示中一网打尽，而深度 Agent 则采用 Orchestrator → Sub-Agent 模式。Orchestrator 将任务委派给一个或多个子 Agent（sub-agents），每个子 Agent 都拥有独立而干净的上下文。子 Agent 在自己的工具调用循环中（搜索、报错、重试）完成工作，整理最终成果，并将综合结果返回给 Orchestrator。
3. 持久化记忆。为防止上下文窗口溢出，深度 Agent 利用外部记忆存储，如文件系统或向量数据库，像 Claude Code 和 Manus 这样的框架为 Agent 提供 read/write 接口。Agent 将中间结果（代码、草稿、原始数据）写入外部存储，后续 Agent 只需通过文件路径或查询检索必要信息，实现了从“记住一切”到“知道从何处获取信息”的范式转变。
4. 极致上下文工程。仅凭“你是一个乐于助人的 AI”式的提示无法激发 Agents 2.0 行为。深度 Agent 依赖高度详细的指令，可能多达数千令牌。PS：结构化、压缩、交互格式。

原理

在 Agent 应用的开发和实践中，核心挑战之一是如何优雅地实现一个可控的循环（Loop）机制。这个循环机制不仅需要能够自动化地执行任务，还要能够在执行过程中根据反馈进行自我调整和优化（Loop+Feedback ）。通过这种方式，LLM 能够模仿人类解决问题的基本方法论，如 PDCA（计划-执行-检查-行动）循环，从而更有效地拆解和解决问题。

认知框架Cognitive Architecture

AgentType 对应一个Agent class，对应一个prompt（又是prompt 起了关键作用），AgentType 有以下几种选择

1. zero-shot ReAct，完全依靠对所用到的tools 的说明书来理解和使用tools，理论上支持无限多个。
2. Structured tool chat，跟第一个不同的地方在于接收一个结构化的dict 作为参数且能记住上下文。
3. OpenAI functions，OpenAI 在大模型层面针对 API的调用做了训练，相当于帮大家做了SFT，可以想象效果必然好。
4. conversational，类似于第一、二类型，针对对话场景做了优化，比如聊天记录、聊天轮次等meta-data
5. self-ask，通过自问自答的方式把大问题拆解成小问题之后再组成最终的单子。

ReAct是 Shunyu Yao 等人在 ICLR 2023 会议论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出的，一个关键启发在于：大语言模型可以通过生成推理痕迹和任务特定行动来实现更大的协同作用。具体来说，就是引导模型生成一个任务解决轨迹：观察环境 - 进行思考 - 采取行动，也就是观察 - 思考 - 行动。那么，再进一步进行简化，就变成了推理 - 行动，是一种将推理和行动相结合的思考链模式（PS：知行合一？），以交错的方式产生与任务相关的语言推理轨迹和行动。ReAct 框架会提示 LLMs 为任务生成推理轨迹和操作，这使得代理能系统地执行动态推理来创建、维护和调整操作计划，同时还支持与外部环境（例如 Google 搜索、Wikipedia）的交互，以将额外信息合并到推理中。PS：使用LLM来做ifelse，ReAct提示大型语言模型为给定任务生成口头推理历史步骤和操作。这些提示由少量的上下文示例组成，这些示例指导模型的思考和操作生成。

与CoT推理一样，ReAct 也是一种提示工程方法，它使用少量学习来教模型如何解决问题。CoT 被认为是模仿人类如何思考问题，ReAct 也包括了这个推理元素，但它更进一步，允许Agent操作文本，让它与环境互动。人类使用语言推理来帮助我们制定策略并记住事情，但也可以采取行动来获得更多的信息并实现目标。这就是 ReAct 的基础（PS：知行合一？）。ReAct 提示包括行动的例子、通过行动获得的观察结果，以及人类在过程中各个步骤中转录的思想(推理策略)。LLM 学习模仿这种交叉思考和行动的方法，使其成为其环境中的Agent。 PS： ReAct是一种Agent行为范式（对比的概念是plan-and-execute/ReWOO:Planner+Worker+Solver），也就是Thought -> Action -> Observation 的循环，也是一种提示工程方法（对比的概念是COT）。

一定要记住，观察结果不是由 LLM 生成的，而是由环境生成的，环境是一个单独的模块，LLM 只能通过特定的文本操作与之交互。因此，为了实现 ReAct，需要:

1. 一种环境，它采取一个文本操作, 从一组可以根据环境的内部状态改变的潜在操作中返回一个文本观察。
2. 一个输出解析器框架，一旦Agent编写了一个有效的操作，它就停止生成文本，在环境中执行该操作，并返回观察结果, 一般是将其追加到目前生成的文本中，并用该结果提示 LLM。
3. 人工产生的示例，混合了思想，行动和观察，在环境中可以使用few-shot，例子的数量和细节取决于目标和开发者的设计

ReAct Agent 的一般提示词结构：

前缀：引入工具的描述
格式：定义React Agent的输出格式

问题：用户输入的问题
思考：React Agent推理如何行动
行动：需要使用的工具
行动输入：工具所需输入
观察：行动执行后得到的结果
（按需重复：思考-行动-观察流程）

终点推理：产生最终结论
最后回答：问题的答案

stop token

How to Get Better Outputs from Your Large Language ModelIt is especially useful to design a stopping template in a few-shot setting so the model can learn to stop appropriately upon completing an intended task. Figure shows separating examples with the string “===” and passing that as the stop word.我们知道一般 LLM 都会长篇大论，说一大堆废话，我们希望 LLM 在返回了我们需要的信息后就停止输出，这里就需要用到stop参数，这个参数是一个列表，列表中的每个元素都是一个字符串，代表了 LLM 输出中的某一句话，当 LLM 输出中包含了这句话时，LLM 就会停止输出，这样我们就可以只获取到我们需要的信息了

代码解释器

ChatGLM3 的代码解释器（Code Interpreter）实现原理：背后的原理其实跟工具调用是一样的。无非就是将普通的函数替换成代码解释器，大模型预测的结果不再是函数的入参，而是具体的代码，根据这些代码我们调用代码解释器执行，然后在界面上面支持显示代码执行的结果。

要了解大模型是如何学会使用代码解释器的，就要先看训练样本是如何构造的。下面是一个官方提供的例子：

<|system|>
你是一位智能AI助手，你叫ChatGLM3，你连接着一台电脑，但请注意不能联网。在使用Python解决任务时，你可以运行代码并得到结果，如果运行结果有错误，你需要尽可能对代码进行改进。你可以处理用户上传到电脑上的文件，文件默认存储路径是/mnt/data/。
<|user|>
帮我画一个爱心
<|assistant|>interpreter
```python
import numpy as np
import matplotlib.pyplot as plt

# 爱心形状的参数方程
def heart(t):
    x = 16 * np.sin(t) ** 3
    y = 13 * np.cos(t) - 5 * np.cos(2 * t) - 2 * np.cos(3 * t) - np.cos(4 * t)
    return x, y

t = np.linspace(0, 2 * np.pi, 1000)
x, y = heart(t)

plt.figure(figsize=(6, 6))
plt.plot(x, y, color='red')
plt.axis('equal')
plt.axis('off')
plt.show()
```
<|observation|>
```result
【image】
```
<|assistant|>
这是一个爱心形状。我使用了参数方程来描述这个形状，并使用matplotlib进行了绘制。如果您有任何其他需求或问题，请随时告诉我。
<|user|>  # End

Claude Skills

PS：Agent ==> skill ==> tool vs team ==> agent ==> tool，在后者的概念里，skill 是规范格式+workflow（向导式多步骤）形态的“agent”，

是什么

利用文件和文件夹构建专业智能体的新方式：Skill就是一个标准化的文件夹，用来打包Agent完成特定任务所需的知识、工作流和工具。可以把它理解成给模型的说明书或标准作业程序（SOP，或者之前比较火的概念：SPEC的增强版）。

1. SKILL.md, 核心文件，必须存在。告诉Claude在什么情况下、以及如何使用这个Skill。
2. YAML Frontmatter (元数据区)：里面用YAML写元数据（name和description）
3. Markdown Body (指令区)：用Markdown 详细说明了执行该任务的工作流程 (Workflow)、最佳实践、注意事项，以及如何调用 scripts 和 references 目录下的资源。
4. scripts/：存放可执行的Python、Shell脚本。
5. references/：存放参考文档。比如API文档、数据库Schema、公司政策等，这些是给Claude看的知识库。
6. assets/：存放资源文件。比如PPT模板、公司Logo、React项目脚手架等，这些是Claude在执行任务时直接使用的文件，而不是阅读的。

它把完成一个特定任务所需的一切都打包好了，本质上就是一种代码和资源的组织方式，一种约定优于配置的理念。当你的Agent能力越来越多时，怎么管理？一个几千行的System Prompt？一个包含几十个工具函数的大杂烩文件？这些都很难维护。而Skills提供了一种解耦的、模块化的方案（可组合性、可扩展性和可移植性）。你团队里的Agent不再是依赖一个巨大的、难以维护的system_prompt.txt，而是一个由几十个标准化的Skill文件夹组成的能力库，每个Skill都可以独立版本控制、测试和迭代。

“Agent Skills” 更是一种架构思想和工程实践，其核心思路在所有主流 LLM 平台上都是通用的：

1. 发现（Discovery）：Agent 如何知道“技能”的存在
2. 加载（Loading）：Agent 如何在需要时获取技能的详细信息（即“渐进式披露”）
3. 执行（Execution）：Agent 如何运行代码或调用 API

发现与加载（未完成）

一些实践

工程落地-定义技能元工具 (skill meta tools)：list_skill/get_skill/run_skill，在 system prompt 里强调这 3 个 tools

- 你具备很多与外部世界互动的能力，但需要通过 list_skill 来了解自己的能力；然后通过 get_skill 了解某项特定能力；最后可以通过 run_skill 来实施具体的能力；
- 通过 list_skill、get_skill 了解到的能力，如果要执行，一定要走 run_skill 方法来执行

大佬

台大李宏毅2025 AI Agent新课来了！李宏毅：

1. AI agent的意思是说，人类不提供明确的行为或步骤的指示，人类只给AI目标，至于怎么达成目标，AI要自己想办法。通常你期待AI agent要达成的目标需要通过多个步骤，跟环境做很复杂的互动才能够完成。而环境会有一些不可预测的地方，所以AI agent还要能够做到灵活地根据现在的状况来调整计划。
2. 来看语言模型，怎么套用到agent的框架下。从llm的角度来看，首先ta得到一个目标，然后接下来得到一个observation，然后根据这个observation，决定接下来要采取什么样的action。当它采取完动作之后，他的动作会影响外界的环境，看到新的observation。看到新的observation以后，要采取新的动作，这个过程就会再反复继续下去。在那一系列的过程中，看到observation采取action，看到observation采取action，其实凭借的都是语言模型原来就有的文字接龙能力。所以从语言模型的角度来看，AI agent并不是一个语言模型的新技术，它比较像是一个语言模型的应用。那用LLM来运行一个AI agent，相较于其他的方法，可能有样什么样的优势呢？
   1. llm可以讲任何话，可以产生各式各样近乎无穷无尽的输出，这就让AI agent可以采取的行动不再有局限，有更多的可能性。
   2. observation可能是电脑的屏幕画面。AI agent要决定的就是要按键盘上哪一个键，或者是要用鼠标按哪一个按钮。
3. 分三个方面来剖析今天这些AI agent的关键能力。

   1. AI agent能不能够根据它的经验，通过过去的互动中所获得的经验来调整他的行为。问题是，如果我们把过去所有的经验都存起来，要改变语言模型的行为，要让它根据过去的经验调整行为，就是把过去所有发生的事情一股脑给它，也许在第100步的时候还行，到第1万步的时候，过去的经验太长了，也许没有足够的算力来回顾一生的信息，就没有办法得到正确的答案。所以怎么办呢？也许我们可以给这些AI agent memory，这就像是人类的长期记忆一样，把发生过的事情存到这个memory里面。当AI agent看到第一万个observation的时候，他不是根据所有存在memory里面的内容去决定接下来要采取什么action，而是有一个叫做read的模块，这个read的模块会从memory里面选择跟现在要解决的问题有关系的经验，把这些有关系的经验放在observation的前面，让模型根据这些有关系的经验跟observation再做文字接龙，接出他应该进行的行动。 有关记忆的部分，是不是要把所有的信息存到memory里面呢？存到长期的记忆库里面呢？如果我们把这些agent经历的所有的事情都放到长期的记忆库里面的话，那里面可能会充斥了一堆鸡毛蒜皮不重要的小事，最终你的memory长期记忆库也可能被塞爆。所以怎么办呢？应该只要记重要的信息就好。怎么让语言模型只记重要的信息就好呢？你可以有一个write的module，那怎么打造这个write的记忆库呢？有一个很简单的办法就是write的模块也是一个语言模型，甚至就是AI agent自己。除了Read跟Write这两个模块以外，还有第三个模块，我们可以暂时叫reflection反思的模块。这个模块的工作是对记忆中的信息做更好的，更high level的，可能是抽象的重新整理。你可以把这些记忆里面的内容，在经过reflection的模块重新反思之后，得到新的想法。那也许read的模块可以根据这些新的想法来进行搜索，这样也许可以得到更好的经验，那帮助模型做出更好的决策。除了产生新的想法之外，也可以为以前观察到的经验建立经验与经验之间的关系，也就是建立一个knowledge graph，然后让read的module根据这个knowledge graph来找相关的信息。

   2. AI agent如何呼叫外部的援助，如何使用工具。
      1. 所谓的工具就是这个东西，你只要知道怎么使用他就好，他内部在想什么，他内部怎么运作的，你完全不用管。其实这些工具对语言模型来说都是function，都是一个函数。它不需要知道这些函数内部是怎么运作的，它只需要知道这些函数怎么给它输入，这些函数会给什么样的输出。因为使用工具就是调用函数，所以使用工具又叫做function call。
      2. 使用工具也有其他的挑战，假设工具很多怎么办呢？假设现在可以用的工具有上百个上千个，那你岂不是要先让语言模型读完上百个上千个工具的使用说明书才开始做事吗？你可以采取一个跟我们刚才前一段讲AI agent memory非常类似的做法，你就把工具的说明通通存到AI agent的memory里面，打造一个工具选择的模块。另外一方面，语言模型甚至可以自己打造工具，，语言模型怎么自己打造工具呢？不要忘了所有的工具其实就是函数，语言模型今天是可以自己写程序的，所以他就自己写一个程序，自己写一个function出来就可以当作工具来使用。放到他的工具包里面，那之后这个工具就有可能在选择工具的时候被选出来，用在接下来的互动中使用。跟模型把过去的记忆，比如说一些比较成功的记忆放到memory里面再提取出来，其实是差不多的意思。
      3. 工具输出有错，语言模型今天是有自己一定程度的判断力的，它也不是完全相信工具，就是语言模型有它内部对世界的信念，这是它的internal knowledge，存在它的参数里面。它从工具会得到一个外部的knowledge，那它会得到什么样的答案，其实就是internal knowledge跟external knowledge，内外的知识互相拉扯以后得到的结果。那什么样的外部知识比较容易说服AI，让他相信你说的话呢？外部的知识如果跟模型本身的信念差距越大，模型就越不容易相信。如果跟本身的信念差距比较小，模型就比较容易相信。模型本身对它目前自己信念的信心，也会影响它会不会被外部的信息所动摇。有一些方法可以计算模型现在给出答案的信心，如果他的信心低，他就容易被动摇。如果他的信心高，他就比较不会被动摇。
   3. 讲AI agent能不能够执行计划，能不能做计划。
      1. 语言模型有没有在做计划呢？也许在给输出的过程中，它有进行计划才给出输出，但是我们不一定能够明确地知道这件事。也许语言模型现在给的输出只是一个反射性的输出，它看到输入就产生一个输出，它根本没有对未来的规划。普遍认为介于有跟没有之间吧，就是你也不能说它完全没有，但你也不能说它真的非常强。但是你可以强迫语言模型直接明确地产生规划。当语言模型看到现在的第一个observation的时候，你可以直接问语言模型说，如果现在要达成我们的目标，从这个observation开始，你觉得应该做哪些行动，这些一系列可以让语言模型达到目标的行为合起来，就叫做计划。而在语言模型产生这个计划之后，把这个计划放到语言模型的observation里面，当作语言模型输入的一部分，语言模型接下来在产生action的时候，它都是根据这个plan来产生action，期待说这个plan定好之后，语言模型按照这个规划一路执行下去，最终就可以达成目标。
      2. 但是天有不测风云，世界上的事就是每一件事都会改变，计划就是要拿来被改变的。所以一个在看到observation 1的时候产生的计划，在下一个时刻不一定仍然是适用的。为什么计划会不适用呢？因为从action到observation这一段并不是由模型控制的，模型执行的动作接下来会看到什么样的状态，是由外部环境所决定的，而外部环境很多时候会有随机性，导致看到的observation跟预期的不一样，导致原有的计划没有办法执行。
      3. 语言模型怎么改变他的计划呢？也许一个可行的方向是每次看到新的observation之后，都让语言模型重新想想还要不要修改他的计划。看到observation 2之后，语言模型重新思考一下，从observation 2要到达他最终的目标，要做哪一些的行为，那这部分的计划形成plan pi。把plan pi放到现在的input里面，把plan pi放到这个sequence里面，语言模型接下来在采取行为的时候，可能会根据plan pi来采取跟原来plan里面所制定的不同的行为。