在2025年，国内人工智能领域有两个里程碑式的事件。首先是DeepSeek的发布，这标志着我们正式迈入了L2级别智能体的大门；随后Manus的亮相，则预示着行业开始进入L2.5时代。

这里提到的L1到L5分级，源于OpenAI的山姆·奥特曼对人工智能应用发展路径的预测。他认为，从L1到L5的演进大约会在十年内完成。

这条技术路线本质上是“模型吞噬一切”的路线。按照这个逻辑，基础模型提供商将成为最大的受益者，所有流量都将向其集中。然而，实际的发展轨迹却并非完全如此。

AI发展史：从L1到L2.5的演进之路

上述的L4和L5阶段尚属遥远，仅看L1到L3的文字描述也难以产生直观感受，需要结合更多背景信息来理解。

2022年底，ChatGPT（基于GPT-3.5）的发布标志着我们进入L1时代，不久之后GPT-4也相继问世。

作为这一时期的亲历者，从模型能力的角度来看，当时最大的问题并非上下文长度不足或存在幻觉，而是资源“一票难求”。普通用户很难获得OpenAI的API访问权限，即便是通过微软Azure云服务获取GPT账号，也常常需要付出高达100%的溢价，且往往有价无市。

同时，模型的推理响应速度也极其缓慢。一次完整的交互，快则需20秒，慢则要等待一分钟。因此，整个2023年，人工智能应用实际上并未达到真正可投入生产使用的状态。

那也是“百模大战”的开端。主流的技术路径普遍采用“预训练+微调”的模式，这个过程耗费巨大。国内走在前列的厂商包括百度、智谱AI、通义千问、讯飞以及百川智能等，但它们彼此之间并未拉开显著差距，其实际能力与开源的LLaMA、Bloom等模型相比也优势不大。

在这个阶段，尽管AI应用大规模进入生产环境尚不成熟，但前期研发环境已经相当完善。特别是在一些对企业级客户而言，费用和响应时间并非首要考量的场景中。因此，那些提供基础设施、研发工具的公司获利颇丰，例如教导普通人使用Coze搭建AI应用的培训服务商，以及各类从事数据生产和数据标注的公司。

然而，芯片行业遵循摩尔定律。由于人工智能热潮吸引了大规模资本涌入，直接导致了模型响应速度大约每半年翻倍、使用成本每半年减半的加速发展态势。因此，到去年年底，所有主流模型的能力都实现了质的飞跃：

1. 业界标杆ChatGPT的响应速度已经变得非常快，基本可以在5秒内完成交互；
2. 智谱AI在推理能力和响应速度上均有大幅提升，阿里的Qwen模型也取得了显著进步。

当然，国内最具标志性的人工智能事件当属DeepSeek的发布。无论是其率先展示的思维链（CoT）技术，还是专家模型等创新设计，都足以让人眼前一亮。这也标志着我们完全进入了L2阶段。

进入2025年，无论是模型的基础推理能力、响应速度还是使用成本，都已达到能够支撑生产应用的水平。因此，业界才将2025年称为“国内AI应用元年”，这个说法正是基于这样的背景。

基础环境就绪后，各类AI应用自然如雨后春笋般涌现。另一个标志性事件随即爆发：Manus发布了。Manus产品的意义不在于其技术难度有多高，而在于它率先提出并实践了一种符合AI时代的智能体产品交互范式。事实上，随后各大浏览器厂商也开始朝这个方向演进，“入口即应用”的思维方式开始普及。

只不过，Manus这类产品在实际使用中仍存在诸多问题。虽然基础模型能力已经足够，但配套的基础设施和工具链尚未完全跟上，这导致其用户体验总感觉“差那么一点意思”。

随后，红杉资本的人工智能峰会也指出，第一批智能体的机会在于垂直领域。果不其然，面向设计师的智能体、面向程序员的智能体在今年取得了长足进步。例如Cursor、Lovart等产品已经切实地改变了部分人群的工作方式。

其次，今年的Google I/O大会展示了众多智能体发展趋势，其中尤其值得关注的是图像/视频生成体系的“Flow + Veo3 + Imagen 4”组合。近期发布的Nano Banana更是火爆异常，文本生成图像的应用似乎近在眼前。

人工智能正在如火如荼地发展，但随之而来的问题是：我们普通人的机会在哪里？我们又需要避免哪些潜在的陷阱？

要回答这个问题，或许需要从智能体的基础架构层面进行审视和判断。

从基础架构视角审视AI领域的机遇

智能体框架的核心技术架构主要包含以下几个方面：

1. 大模型负责解决规划与调度问题。Manus能够爆发的核心原因正是模型能力的显著增强。
2. RAG（检索增强生成）技术用于缓解幻觉问题。就当前模型发展趋势而言，上下文窗口突破百万级别是迟早的事。如何让模型对话更像真人，以及体验良好的AI数字分身类应用，预计将在未来两年内诞生。
3. 工具链旨在解决多模态交互问题。最近颇受关注的MCP（模型上下文协议）、Computer Use等，本质上都是AI多模态能力的延伸，目的是解决AI在各种感官交互（如听觉、视觉、触觉）上的局限性。

从基础架构出发，一条关于基础能力的“红线”也随之清晰：例如，切勿轻易涉足多模态相关领域！

包括语音识别与合成、视频生成、文生图、图生文、视频语音处理等方向，接下来将迎来大规模的行业洗牌，普通公司最好不要轻易涉足。

另一方面，当前的记忆模块主要依赖RAG技术，但未来这一部分可能会有不小的迭代。模型可能会预留更合适的接口，以便我们更高效地注入领域知识。然而，这其中涉及的数据安全问题也不容小觑。

此外，在模型上下文窗口持续扩大（例如超过10万token）的趋势下，传统的向量数据库等技术，可能在未来几年内逐渐退出历史舞台。

一个好消息是，模型的幻觉问题是难以从根本上彻底解决的，因此企业不必过分担心数据壁垒最终会完全消失。正如OpenAI近期发表的论文《Why Language Models Hallucinate》所指出的：

幻觉并非神秘的缺陷，而是训练与评估过程中，奖励“猜测”行为、惩罚“不确定”表达的统计性后果。 降低幻觉，需要在评估中对过于自信的错误答案施加重罚，对合理的不确定性给予部分分数，并允许模型在不确定时选择“弃答”或“请求澄清”。 RAG可以缓解事实性错误，但若底层激励机制不改变，猜测行为仍会发生。

再看如今常见的智能体，大致可以分为两类：通用型智能体和垂直行业智能体。

对于通用型智能体而言，其核心在于工具生态，生态越繁荣，产品越容易脱颖而出。而对于垂直行业智能体来说，私有的领域语料库、垂直领域的专用插件越多，其在实际使用中的友好度和有效性就越高。

以Manus类产品为例，其本身并没有过高的技术壁垒。国内已有不少类似产品，其基本功能的实现周期大约在一个月左右。当然，如果要打磨到体验出色，仍需投入大量时间。

为了让读者更清晰地理解智能体架构，我们接下来将利用Coze这一工具，尝试简单实现一个“类Manus”系统，以便大家对智能体架构的核心工作量分布有一个更系统的认识。

Manus核心原理简要分析

在开始动手实现之前，有必要了解一下 Multi-Agent System（多智能体系统） 的概念。

智能体的最佳实践遵循“单一职责”原则。所谓的多智能体系统，就是指一项工作由多个职责分明的智能体协同完成。至于如何调用这些智能体，则需要大模型进行详细的规划和调度。而Manus在本质上，就是一个多智能体系统。

实例解析：一个贪吃蛇游戏的诞生

举个例子：打开Manus，让它“帮我做一个贪吃蛇游戏”，它很快就能完成任务。

在这个过程中，它可能调用了以下工具能力：

1. 文件读写能力；
2. 浏览器操作能力（包括网页搜索、模拟点击、键盘事件等）；
3. 代码编写与纠错能力；
4. 系统命令执行能力；
5. 代码部署与预览能力；
6. ……

所有这些操作都在一台云主机上完成，并且实时回传了运行进展。其简化版的架构猜想如下（注：真实场景中，规划与记忆模块会复杂得多，此处仅做原理性示意）：

回顾过去一年的热门技术事件，DeepSeek的发布与Manus的问世无疑是两个最受瞩目的焦点。市场对这类产品展现出持续的热情，近期爆火的Agent形态产品OpenClaw（由Clawdbot演进为Moltbot）便是例证。

关于为什么需要Agent以及它究竟解决了哪些核心问题，我们在之前的文章中已有详细阐述。今天，我们将采取一种更为务实的视角，直接带领大家动手构建一个Agent，通过实践来深入理解其背后的技术难点与实现逻辑。

一、环境配置：从零搭建开发环境

在开发过程中，不同的项目往往需要不同版本的Python运行环境。为了高效管理多个Python版本，我们推荐使用pyenv这一工具。

macOS系统可以通过Homebrew进行安装：

brew update
brew install pyenv

或者，您也可以选择使用官方安装脚本：

curl https://pyenv.run | bash

Linux与Windows系统的安装命令如下：

curl -fsSL https://pyenv.run | bash

# Windows系统需使用pyenv-win：
# 1. 以管理员权限打开PowerShell。
# 2. 执行以下安装命令：
Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

安装完成后，可以通过运行以下命令来验证安装是否成功：

pyenv --version

若成功显示版本号，则表明安装正确。以下是一些常用的pyenv命令：

# 查看所有可安装的Python版本
pyenv install --list | grep 3.12
# 安装指定版本的Python，例如3.12.0
pyenv install 3.12.0
# 查看当前已安装的所有Python版本
pyenv versions
# 设置全局默认的Python版本
pyenv global 3.12.0
# 仅为当前目录设置特定的Python版本
pyenv local 3.12.0

Python包管理工具：uv

uv是一个轻量级的Python包管理工具，它集成了虚拟环境管理和依赖包管理功能，可以看作是pip与venv的组合体。使用uv能够方便地为不同项目创建独立的虚拟环境，并精确管理依赖版本。

确保已通过pyenv安装并切换至所需版本的Python后，即可安装uv。

macOS / Linux系统可通过官方脚本安装，或使用pip安装：

curl -fsSL https://uv.dev/install.sh | bash
# 或
pip install uv-cli

Windows系统的安装步骤如下：

根据当前的市场反馈，多数公司的AI应用仍停留在使用Coze、Dify等平台搭建基础知识库的阶段。因此，若能深入掌握上述任一主题，在求职市场上便已具备显著优势。

然而，若希望进入专注于“真AI应用”的团队，或应对技术深度要求更高的面试，仅掌握单一知识点可能显得不足。此时，将Agent与RAG两者融合的 Agentic RAG 概念便应运而生，它能显著提升系统的智能化水平。

Agentic RAG 自诞生之初，便被视为一种更高级的解决方案，随之而来的一种常见论调是 “RAG已经过时”。

就在昨日的一次AI闭门讨论会上，这一观点再次出现：一位资深投资人士在推崇Agent的同时，不自觉地质疑RAG的价值。但若深入追问其参与过哪些深度RAG项目，往往又无法得到实质性的答案。

尽管如此，我们仍需厘清当前所谓的 “RAG过时论”究竟指什么。本质上，大语言模型仅具备输入和输出接口，任何在输入前对问题进行干预处理的过程，广义上均可被视作RAG的范畴。从这个角度看，RAG作为一种范式本身并不过时。

重新审视“RAG过时论”

技术迭代中，不好用的方法被淘汰是共识。这里所指的“过时”，通常是针对前几年兴起的 “朴素RAG” 模式： 进行一次向量检索，将Top-K的文本块直接塞入提示词，最终导致“垃圾进，垃圾出”。

这种模式最突出的问题是上下文割裂：在对原始文档进行分块时，破坏了文本的完整性，例如切分了表格、打断了论证逻辑，最终导致信息丢失。

于是，一个自然的疑问产生：既然分块导致问题，而如今模型上下文窗口极大（百万级上下文也即将普及），是否可以将整个文档直接交给模型，从而避免分块？

答案可能并非如此。虽然长上下文可以缓解因分段造成的语义割裂，但背后的检索效率与精度问题依然存在，因此分块仍是必要步骤，主要原因如下：

主流文本嵌入模型有其最佳的编码长度（通常是中等长度）。将一本数万令牌的书籍编码成一个向量，就如同用一句话概括全书，大量细节必然丢失，导致检索精度急剧下降。这一点或许需要进一步解释：

每个基座模型都提供嵌入接口，它并不关心输入量的大小，无论是200字还是2万字，最终都会将其压缩为一个向量。结果是：输入文本越长，承载信息越多，压缩就越剧烈，生成的向量往往更“平均化”，从而导致检索分辨率降低。

信息在传递过程中具有扩散和压缩的特性，并非越多越好。

然而，当文档结构化做到这种程度时，我们完全可以为每个子文档先归类，再为其生成一段摘要描述。当问题到来时，可先通过穷举匹配进入具体类型，再利用小型模型判断摘要的相关性，这种方法效率很高，有时甚至可以不再依赖向量数据库。

因此，在真实场景中，向量数据库并非唯一选择，多种技术常常混合使用。

随着智能体需求的激增，模型侧对智能体的基础支持进行了大量优化，包括提出了MCP、Skills等概念。可以说，工具链中最令人头痛的问题已得到相当程度的解决；明年，模型很可能在记忆侧发力，给出更优秀的工程策略。

举例来说，理想的知识数据处理流程是：将文档全量喂给某个智能知识库，当进行知识检索时，该智能知识库能够给出准确答案。过去，大家使用向量数据库进行语义检索，但效果不佳，需要叠加大量工程技术才能勉强实现。后来人们发现，小型模型配合结构化知识库也能完成语义检索，何必非用向量数据库？于是，整个工程范式发生了很大变化。

如何将这类复杂的工程技术内化并封装，如何将向量检索技术内置到模型黑盒中，这可能是下一代模型技术需要突破的命题之一。

在大致解释了何为“过时的RAG”（尽管我们并不完全清楚批评者具体所指）之后，让我们回归到Agentic RAG的主题。

Agentic RAG：定义与核心理念

为了获得更好的AI应用体验，我们在工程层面进行了诸多优化，包括：多源知识整合、更动态的上下文验证、与外部工具的深度融合等。

当Agent概念兴起后，大家发现可以利用计算成本（Token）来换取架构的简化，通过多次循环迭代的增量成本，来解决工作流泛化的工程难题。

于是，便有先行者思考，是否可以引入 Agentic RAG 的概念，使其能够进行精细的计划、多步骤推理，并充分利用外部工具来处理复杂问题。

总而言之，所有冠以“Agent”之名的技术，其出现都是为了降低工程复杂性，是一种用（计算）时间换取（系统）架构简化的范式。

Agentic RAG的核心工作是：在多个文档和数据源之间比对信息、提炼总结，从而产出全面且准确的答案。换言之，它实现了从被动检索到主动推理的转变，将静态的问答过程升级为动态、智能的知识探索过程……

注：可以看到，但凡沾上“Agent”字样，描述就显得颇为玄妙。

下图展示了传统RAG（上）与Agentic RAG（下）的流程对比：

Agentic RAG采用循环迭代流程：引入Agent对查询进行分析和决策，例如决定是查询内部知识库还是进行网络搜索，然后对检索结果的相关性进行评分。如果结果不理想，Agent会改写查询重新检索。如此反复，直到收集到足够有用的上下文，再由大语言模型生成可靠答案。

换句话说：Agentic RAG 是一种泛化能力很强的工作流架构，能够让模型自主获取更优质的数据。

我知道大家可能仍有些困惑，让我们看一个之前的实际案例。

从实践案例看传统RAG的局限

成都某大型律师事务所曾有一个需求： 在审阅一份800页的跨境并购协议时，需要快速定位数十个关键条款（如赔偿、终止、担保、知识产权转移等），并对每个条款的风险点进行初步分析。一位资深律师完成全面审阅需要40-50小时。

他们的负责人询问能否用10万元预算通过AI解决。我回答可以，并且付诸实践，也“解决了”问题。只不过，系统的可扩展性不高，毕竟10万元的预算不可能打造出一个Harvey（知名法律AI）级别的产品。

初期，我们尝试了一种基于Dify的标准方案：

1. 文档处理：将PDF合同转换为文本，按固定长度（如512字符）进行重叠分块。
2. 向量化：使用Dify的知识库功能自动处理分块与嵌入。
3. 检索：用户提问时，召回相似度最高的Top-5个文本块。
4. 生成：将文本块与问题拼接，提交给GPT-4生成答案。

实际效果堪称灾难：

一、关键条款信息丢失

一些“条款”可能跨越3-5页，包含定义、范围、限额、除外情形等多个部分。固定长度的分块会将其切割成5-6段，导致每段语义都不完整。

二、表格数据丢失

合同附录中包含大量表格，通常需要转换为Markdown格式。如果未做处理或处理不当，表格会被切碎，模型可能只看到表头或零星数据。

三、引用混乱

模型常常自信地引用“第523页第2段”，但实际上该页讨论的是完全不同的内容。甚至出现过引用页码超出了文档总页数的情况。

四、图片信息缺失

这一点无需多言，图片未经特殊处理（如转化为Markdown并添加描述），信息几乎全部丢失。

五、答案一致性差

针对同一问题在不同时间提问，得到的答案和引用来源完全不同，完全无法用于正式的法律意见书。只要错一处，律师便会怀疑所有结果的可靠性。

近期，上海交通大学发布了一篇题为《上下文工程2.0：上下文工程的上下文》（Context Engineering 2.0: The Context of Context Engineering）的论文。该论文试图系统性地梳理上下文工程这一概念的演进路径，在给出基本定义后，概括性地描述了从1.0到4.0的不同阶段划分。

通读全文，其论述较为抽象和晦涩。可以感受到，作者的核心意图是希望清晰地界定到底哪些信息构成大模型的有效输入。

为了完成这项定义工作，论文甚至追溯至GPT-3.0之前的时代，并最终给出了一个四阶段划分：1.0代表原始计算时代，2.0是智能代理时代，3.0对应人类水平时代，4.0则是超人类时代。

坦率地说，我并不推荐大家深入研读这篇论文，因为它可能难以直接解决我们面临的实际工程问题。论文的核心观点其实可以浓缩为一句话，尽管表述得有些拗口：

上下文工程的核心使命，是将人类高熵的意图转换为机器可理解的低熵信息。

为了让这句话更易于理解，我们可以稍作阐释。当前的大语言模型在设计上可以视为一套**“压缩-扩散”**体系。首先，用于训练模型的数据集本身就难以完整、精确地表征真实世界的复杂性；其次，正因为输入信息本身是残缺和不完美的，模型的输出自然也可能出现问题。

这并不完全是模型自身的缺陷，因为人类在交流中同样面临类似困境：

在实际对话中，只要交流双方的背景信息不同步，误解就极易产生（有时即便信息同步，误解依然可能发生）。

因此，一个基本的结论是：当前的大模型在理解现实世界方面存在“本质缺陷”。当然，论文中也指出，这个问题未来终将得到解决。强化学习之父Rich Sutton在其著名的**“苦涩的教训”**一文中不仅赞同问题可解，更提出了具体策略：依靠海量计算资源，简单而通用的方法终将胜出，并以AlphaGo的成功作为例证。

然而，模型迭代在现阶段确实遇到了现实的瓶颈。暂且不论高质量训练数据是否面临枯竭或难以获取的挑战，最根本的问题在于，现实世界的复杂度远非围棋棋盘或文本序列所能比拟。计算力必须作用于正确的架构之上，才有可能实现真正的突破。

当前的LLM，其本质是基于海量文本训练的“词序列条件概率模型”。它擅长学习“在特定上下文环境下，下一个词最可能是什么”，这体现了一种强大的统计拟合能力，但距离真正的理解与逻辑思考尚有距离。

从这个角度看，前文提到的某些定义或许意义有限。在实际工作中，我们依然需要逐个调试提示词，进行大量工程实践。因此，这篇论文并未旨在解决我们实际工程应用中的难题，但它的出现及其论述方式，确实引发了我对相关领域现状的一些思考。

AI与数据的交互：复杂项目的核心挑战

真正参与过复杂AI项目开发的工程师都会深刻理解，在AI应用层，最艰巨的任务往往是：如何实现数据与AI的高效、精准交互。

例如，我曾研究过数个生产级别的复杂AI项目，其核心代码量可能仅在一万行左右，但所依赖和整合的知识库却规模惊人。这种强烈的非对称性导致了一个普遍现象：在复杂AI项目中，团队80%以上的开发时间都投入在处理数据相关的问题上！

正因如此，业界对于复杂AI项目中AI与数据交互的标准化范式与最佳实践抱有极高的关注度。不过，我个人对堆砌各种新名词（如短期记忆、长期记忆、语义记忆、情景记忆等）的做法持保留态度。

甚至，我曾对“上下文工程”这个术语本身也感到不适。在我看来，与模型的交互本质极为简洁：仅包含一套输入和输出（即API调用），除此之外别无他物：

基于我过去三年完整参与AI项目开发的经历，从1.0阶段的“百模大战”（大家竞相卷训练），到2.0阶段的“套壳时代”（普遍应用简单的RAG技术），再到当前的3.0阶段（开发者开始依据数据构建复杂的思维链，即CoT），其中的关键分水岭在于模型是否具备识别与遵循CoT的能力。

在提示词工程主导的阶段（1.0和2.0），面临的尴尬局面是模型理解能力有限且上下文长度不足，往往无法基于正确的输入获得理想的输出。因此，在AI与数据交互的设计上，大家普遍采取保守且简单的策略。

随着模型推理能力的显著进步，现在的模型已经能够很好地理解并执行CoT。正是在此基础上，构建复杂AI应用才成为可能。然而，这也意味着技术路径开始出现真正的分叉，其核心区别在于：CoT所包含的推理步骤及其所需的数据，究竟是由开发者强控制提供的，还是由AI自主生成的？

更具体地说，关键在于：提示词中运用的是人为设计的CoT，还是由AI自行衍生的CoT？

两种CoT范式的分野

首先，何为“人为CoT”，何为“AI CoT”？ 下面这张图或许能提供一个初步的说明：

但要彻底厘清两者的区别，可能需要从AI项目的构建目标谈起。以我之前开发的“群聊分身”项目为例，其目标是在管理学科领域，构建一个能模拟我的思维方式与表达习惯的智能体，使其能够替我完成管理相关的咨询工作。

其中，“模拟我的思维方式”包含两个层面：

第一，KnowHow（技术诀窍）。即我究竟是如何思考的？这实际上是一套内化于我大脑中的决策算法，需要将其外化翻译出来，其具体的产物就是“工作流程”（Workflow）或“标准操作程序”（SOP）。

第二，数据。SOP无法在真空中执行，它需要调用我大脑中存储的管理领域相关知识，这些知识此前已被我整理成约40篇的管理课程文章。

综上所述，这套CoT实质上是 “算法（SOP）+ 数据” 的组合体。它也正是我们所说的 “AI与数据的交互范式”。

这种交互范式对我们的工程能力提出了明确要求：能够获取数据、能够获取正确的数据、能够获取充足的数据（包括完整的关系链与逻辑链）。在满足这些基本要求的前提下，才谈得上对成本与效率的优化，例如避免获取冗余数据。

所谓人为CoT，即指由开发者自行构建这套SOP与数据结构；而AI CoT的思路则是：何必如此费力？让AI来协助甚至自主完成SOP和数据的组织工作。

这样的表述可能仍有些抽象。我们可以以大家最熟悉的RAG（检索增强生成）场景为例，简要描述其演进逻辑：

范式原理的进一步阐释

在人为CoT的方法论中，问题求解的步骤与逻辑完全由人类开发者预先设计和编排。

我们需要将内在的思维流程（KnowHow）翻译成显式的SOP或Workflow，并严格控制模型严格按照这些既定步骤执行。例如，面对一个复杂任务，我们可能预先定义：“第一步执行分析A，第二步根据A的结果执行操作B，第三步查询数据库C，第四步综合给出最终结论”。模型在这种模式下，更像是在执行一个人类预先编写好的精密脚本，每一步需要何种数据、进行何种处理都被明确规定。

AI CoT方法则将这种规划与控制权在很大程度上交还给模型本身。我们仅向模型提供一个总体目标或高层级提示，由它自行决定如何分解问题、采取哪些具体的推理步骤。模型可能在内部自主生成一系列链式思考（类似于人类在脑海中进行推理的过程），自主决定执行的先后顺序。简而言之，人为CoT是我们替模型规划好每一步路径，而AI CoT则是为模型设定目标，让它自己去探索和开辟路径。

相应地，在数据交互层面，两者也存在显著差异。

在人为CoT范式下，模型推理所需的知识片段是由开发者显式、主动提供的。也就是说，我们确保模型在推理时能够“看到”所有必需的低熵（高确定性）信息。一个典型例子是经典的RAG流程：我们先从知识库中检索出与问题相关的文档片段，经过人工整理或简单拼接后，将其置入提示词中，再让模型基于这些给定的内容生成答案。整个过程中，检索什么、提供什么、以何种顺序提供，都主要由人为决定。

AI CoT则尝试让模型自己去主动“索取”数据。模型在推理过程中，可以自行意识到需要某些额外信息来推进思考，然后自主调用外部工具（如搜索引擎、数据库查询接口、函数API等）来获取新信息，再基于新信息继续推理。换言之，在AI CoT模式下，模型不仅思考“下一步该做什么”，还会自行判断“我需要什么额外信息”并主动尝试获取，使得数据与AI的交互过程更具自主性和动态性。

两者之间最根本的区别之一在于工程上的可观测性与可控性。

AI CoT的简单实现逻辑

阐述完基本原理后，我们来看看这两种思维链范式在实际项目中是如何运作的。人为CoT的流程大家可能比较熟悉，这里我们将重点介绍AI CoT的实现思路。我们继续以大家熟知的RAG场景为例，说明其演进逻辑。

实现AI CoT的关键在于：引导模型输出其内部的思考过程，并为模型提供工具接口，让它能够自主发起检索动作。

在实际运行时，模型会首先接收到用户的问题，并可能产生类似“Thought：我需要先理解问题的核心，并确定缺失哪些关键信息”的思考。接着，它可能输出一个“Action：搜索关于[特定概念X]的详细定义或最新资料”。系统在监听到这个动作指令后，便执行一次知识检索操作，并将检索结果作为新的上下文信息反馈给模型。

在我们探讨AI项目的技术选型时，一个常见且关键的问题是：构建AI应用应该选择哪个框架？ 讨论中频繁出现的名字包括Coze、Dify、FastGPT、n8n，以及LangChain。

对于那些偏好深度控制和“亲手编写代码”的开发者而言，拖拽式的低代码平台往往并非首选。在众多选项中，LangChain通常被认为是技术层面更优的选择。

LangChain与LangGraph作为当前主流的AI Agent开发框架，为开发者提供了一套从基础组件封装到复杂流程编排的完整工具链。随着LangChain 1.x与LangGraph 1.x版本的日趋成熟，整个技术栈的生态分工与工程化实践路径也变得更加清晰。本文将深入剖析这两个框架的核心概念、演进历史、核心功能及其实际应用场景。

LangChain的发展历程

LangChain由Harrison Chase于2022年10月创立，最初定位为一个专注于“使用大语言模型构建应用程序”的开源框架。彼时，ChatGPT刚刚掀起全球的AI热潮，开发者们急需一种能够快速连接LLM与外部数据源、工具及API的解决方案。

一、抢占先机

LangChain的诞生恰逢其时。它本质上是对一系列LLM应用最佳实践的抽象与封装，提供了几个关键的抽象层：

1. Models（模型）：对各种大语言模型进行统一封装，提供标准化的推理与对话接口，构成系统的基础能力层。
2. Chains（链）：将多个独立组件串联起来，形成可执行的工作流。
3. Tools（工具）：为LLM提供调用外部能力（如API、数据库）的接口。
4. Agents（代理）：实现让模型自主决策、调用工具的执行机制。
5. Memory（记忆）：负责管理对话历史与中间状态，使模型在多轮交互中保持上下文连贯性。

该框架极大地简化了LLM应用的开发流程，使开发者能够快速搭建问答系统、文本摘要工具和对话机器人等。在早期阶段，许多高级功能并不突出，可以简单地将LangChain理解为实现RAG（检索增强生成）的便捷工具。

然而，LangChain的早期架构采用了**单体式（Monolithic）**设计，所有组件紧密耦合。这种设计虽然便于快速集成，但也带来了扩展性方面的挑战。因此，许多团队在实际项目中更倾向于参考其设计思想，而非直接使用其全部代码。

二、快速迭代

如前所述，在ChatGPT早期，模型本身能力有限且算力成本高昂，因此在生产环境中直接使用LangChain的情况并不普遍。但从2023年开始，模型能力几乎每半年就有显著提升，LangChain也随之快速迭代，不断弥补自身的短板，例如：

1. 模块化设计更加合理，各组件能够灵活组合。
2. 支持了更多模型提供商（如OpenAI、Anthropic、Google等）。
3. 生态系统日益丰富，社区贡献了大量第三方集成。

不过，这一时期的AI开源框架普遍面临一些共性问题：

1. API变更频繁，破坏性更新较多。
2. 代理（Agent）逻辑分散，难以维护复杂的业务流程。
3. 状态管理能力相对薄弱。
4. 对于需要长期记忆和状态持久化的应用支持不足（这不仅是框架问题，也与当时模型能力有限有关）。

值得一提的是，如今大热的智能体（Agent）概念在2023年仍处于萌芽阶段。当时，AgentExecutor是实现智能体的核心组件，它通过一个**硬编码的循环（Hardcoded Loop）**来执行ReAct逻辑。这种“黑盒”设计使得开发者很难定制复杂的执行流程，例如加入人机交互或错误重试机制。

三、应对复杂需求：LangGraph登场

随着模型能力的持续增强，AI项目的复杂度也水涨船高。LangChain团队意识到，简单的链式结构已无法满足高级Agent开发的需求。

因此，LangGraph作为一个专门的编排框架应运而生。它的核心设计理念包括：

1. 基于图结构：采用节点（Node）、边（Edge）、状态（State）三大核心抽象。
2. 支持复杂流程：能够处理循环、条件分支和并行执行。
3. 状态持久化：通过检查点（checkpoint）机制实现状态的保存与恢复。
4. 人工介入：支持“人在回路”（Human-in-the-Loop）的交互模式。

这依然是一个过渡阶段。直到2025年，模型能力真正达到了新的高度，LangChain 1.0 才正式发布。

1.0正式版发布

2025年10月，LangChain 1.0与LangGraph 1.0同步发布，这标志着这两个框架进入了首个稳定版本阶段。以“1.x”开头的版本号通常意味着更高的稳定性，开发者可以更放心地将其用于生产环境。

在后续发展中，版本稳定性将得到更多重视：与早期的快速迭代相比，1.x阶段更强调API的向后兼容性与平滑的迁移路径，从而降低维护成本。同时，LangChain与LangGraph的定位边界也更加清晰：

1. LangChain：更偏向于应用层的组件与集成，强调易用性和快速拼装。
2. LangGraph：更偏向于底层的流程编排与状态管理，强调可控性、可恢复性和可扩展性。

接下来，我们简要探讨一下1.0版本与旧版本的主要区别。

1.0 版本的重要特点

首先是整体架构上的重大变化。在1.x生态中，一个明显的趋势是：LangChain更聚焦于提供应用层的能力与集成，而LangGraph则更适合作为流程编排与状态管理的“底座”，被引入到复杂的Agent场景中。

在实际项目中，二者的组合方式会因具体版本、编程语言包和团队选型而有所不同，但整体方向是让流程控制变得更加显式、更易于维护。

这一架构转变使得LangChain从一个流程执行框架，演进为面向开发者的应用层SDK，带来了以下显著优势：

1. 运行时能力下沉，职责边界更清晰。
2. Agent执行模型得到统一，减少了隐式行为。
3. 具备了更强的可扩展性与可观测性。
4. 为复杂Agent场景提供了工程级别的稳定性保障。

其次，在应用层的易用性上，LangChain 1.0展现了强大的应用性和生态整合能力：

1. 提供了高级API抽象，例如create_agent等便捷的Agent构建接口。
2. 内置了丰富的可复用组件，包括：
   • Agent构建工具
   • 预构建的Chains（任务链）
   • Retrievers（检索器）
   • Tools / Tool Calling 抽象
   • Middleware（中间件/回调）机制

在编排层，LangGraph作为面向系统的统一Agent运行与编排引擎，是LangChain 1.0的核心基础设施，扮演着“总控制器”的角色：

首先，必须重申那个根本性问题：在当今模型能力如此强大的背景下，提示词已经可以胜任大量工作，我们为什么仍然需要进行微调？

一、为什么需要微调：超越提示词

当前AI应用开发面临一个现实：许多微调能够完成的任务，似乎完全可以通过精心设计的提示词来实现。这很容易让我们产生一种错觉：提示词和微调在本质上没有太大区别，它们都旨在影响模型的输出预测；如果非要说不同，可能只是微调在特定任务上的定制化能力更强一些。

然而，两者的底层逻辑存在显著差异：提示词本质上是一种“引导”，而微调则是一种“改造”。导致两者泛化能力强弱不同的关键在于，提示词属于输入层面的控制，模型本身的“大脑”并未改变；而微调则是在参数层面进行迁移学习，直接改变了模型的“脑回路”，使其对特定任务的模式变得敏感。

以下几个场景，虽然通常可以使用提示词解决，但在某些特定情况下，微调的必要性便会凸显。

1.1 简单意图识别

以一个管理场景下的意图分类任务为例，目标是将管理口语归类为以下五个意图之一：

• A 目标不清
• B 忙闲不均
• C 管理者精力不足
• D 员工精力不足
• E 沟通迟滞

使用提示词可以轻松处理大部分标准表述：

用户：A组加班到半夜，B组一堆人闲着刷手机
输出：{"label":"B"}

用户：产品目标周周变，大家都不知道先做哪个
输出：{"label":"A"}

在这种主流、规范的表述下，提示词的准确率通常非常高，可能超过95%。然而，当遇到以下复杂情况时，其表现可能大打折扣：

1. 表述变异过大：当输入中包含大量方言、口语化表达、行业黑话甚至错别字时，模型理解可能产生偏差。例如：“俺们组肝到秃头，隔壁组摸鱼划水？那还加锤子班？”
2. 多重转折：如果一个句子包含了复杂的逻辑转折，模型可能难以准确把握核心意图。例如：“虽然不像以前那么忙了，但是目标天天变，更累了。”
3. 边界模糊：当一句话同时涉及多个意图且没有明显倾向性时，不同模型可能给出不一致的答案，影响系统稳定性。例如：“老板口径每天变 vs 岗位职责说不清”。

如果产品在此类场景下表现不稳定，且通过优化提示词无法有效解决，那么微调就该登场了。微调可以通过提供针对性样本，直接“教会”模型如何应对这些边缘情况：

{"text": “俺们组肝到秃头，隔壁组摸鱼划水”， “label”: “B”}
{"text": “虽然不像以前那么忙了，但是目标天天变，更累了”， “label”: “A”}
{"text”: “老板和大伙儿都蔫儿了，干啥都提不起劲”， “label”: “C”} // 此处融合了C和D的表述，需根据明确的定义进行标注

1.2 槽位抽取/关键词提取

这是大模型应用中的常见任务，用于判断一句话中是否出现或否定了多个特定概念。

用户：不是大家偷懒，更像任务拆分有问题
输出：{"present":[], "negated":["管理者长期疲惫影响节奏"]}

用户：A线忙疯了，B线一堆人闲着
输出：{"present":["部分人很忙、部分人很闲"], "negated":[]}

当任务对判断准确率要求极高，且提示词在处理复杂否定句或微妙语义时频繁出错，微调的优势便显现出来。它可以显著提升模型对特定模式（如多重否定、特定黑话否定）的识别精度。

{
  "text": “我觉得不是员工精力不足，而是管理者不会分配任务”，
  "output": {
    "present": [],
    "negated": ["管理者精力不足"]
  }
}

上述管理场景还算相对简单，因为语言模型本身对这类通用问题有一定认知。但如果需要识别的特定概念是公司内部的黑话或高度专业术语，复杂度将急剧上升。此时几乎不能依赖模型的先验知识，解决方案只有两个：要么在每次提示词中附带详尽的术语解释（成本高且低效），要么就通过微调将这套“新语言”内化到模型中。

1.3 微调是“笨办法”但有时必要

从上述案例可以看出，微调本身也是一种相对“笨重”和直接的方法。它同样有其局限性，例如面对标签定义本身重叠、用户表述自相矛盾或语义极其模糊的场景时，微调模型也可能无能为力。

此外，微调的前期投资回报率通常较低。它更适合处理海量、重复且对准确性有苛刻要求的任务。例如，在万级别的处理量下，1%的错误就意味着上百个客户被误分类，此时的边际收益才能覆盖微调的成本。当数据量不足时，频繁调整提示词或许更为灵活。

在实践中，笔者在槽位抽取任务中选择微调，有时并非纯粹出于准确率的考量，而是为了追求更快的响应速度。通过针对特定任务微调一个轻量级模型，可以在获得可接受精度的同时，实现远超大模型的推理速度，并且完全避开了让大模型去记忆大量专业黑话的难题。当然，在通用性和灵活性上，提示词方案目前仍更具优势。

因此，当面对复杂、独特或高度模糊的分类任务——即常说的意图识别和槽位抽取（关键词提取）——时，微调的价值才真正凸显。

二、意图识别：小模型的挑战

在深入探讨槽位抽取（关键词提取）之前，有必要特别讨论一下意图识别是否能用更小、更高效的模型通过微调来替代大模型。根据个人实践经验，对于复杂场景，答案是比较悲观的。

在人类数十万年的进化历程中，文字书写与阅读的出现仅数千年，而语音和视觉始终是我们最高频的沟通方式。

因此，仅依赖文本交互的AI产品已远不足以满足需求，各大企业对于AI在语音侧“接口”的争夺也从未停止，原因如下：

1. 单位时间信息密度：人们说话的速度远超打字，语音交互能大幅提升信息输入与输出的整体效率。
2. 数据价值：日常沟通中蕴含着大量有价值的信息。过去这些口头交流往往无法沉淀为数据资产，而语音AI可以将“声音”数字化，进而转写成文本甚至结构化的知识。
3. 市场价值：据预测，2025年全球语音识别市场规模可达约267.9亿美元，该技术正广泛应用于汽车、医疗、消费电子等诸多行业。
4. 其他潜在因素……

基于此，钉钉在前两个月的十周年发布会上推出了其首款AI语音产品——钉钉A1。起初我并未拿到实体硬件，推测当时可能仍是原型机阶段，而在最近的发布活动中终于成功上手体验。

我们首先看看官方对其的定位：会议助手、销售助手、客服助手……

钉钉A1的核心功能与应用场景

A1的技术实现逻辑相对清晰：它借助钉钉最新发布的DingTalk_AI（原先可能称为AI听记），将录制下的语音实时转写成文字，并通过大模型进行总结与提炼。

可以简单理解为，硬件部分充当了一个语音输入设备，而DingTalk_AI则是一个功能展示模块。现阶段，无论是会议、面试还是销售拜访，该设备都能自动整理关键要点，生成纪要和分析报告。

例如，人力资源专员借助A1记录面试过程后，可在钉钉内查看自动提炼的候选人履历、情绪状态、沟通能力分析等内容，辅助其快速筛选合适人才。

针对客户服务交流，A1能够提取客户基本信息、需求分类及满意度指标，帮助客服人员更清晰地了解服务质量与改进方向。

之所以能处理这些看似“需求百变”、“杂乱无章”的场景，是因为A1内置了超过30种场景化的AI纪要模板，覆盖学习笔记、日常记录、会议纪要、面试记录等多种情况，用户只需选择相应模板即可生成结构清晰的总结。

但我们之前提到：A1本质上是一套硬件输入、平台处理的系统。从逻辑上讲，钉钉完全可以将这个处理模块开放出来，让各类企业在其基础上开发出丰富多彩的应用！例如：

1. 销售或客服的对话记录可被提炼为潜在的销售线索和客户意向分析；
2. 人力资源部门的面试记录可衍生出详细的候选人评估报告；
3. 行政人员的会议记录则可自动转化为任务清单和日程安排；
4. 其他各类定制化需求均可被实现。

这意味着，目前大家在A1上所见的所有功能或许只是一个初步示范，未来基于此平台的各类应用都有可能出现。与其说A1是一个单纯的AI语音产品，不如将其定义为一个AI语音开放平台。

按照这一发展趋势，A1的硬件设备成本可能会逐渐降低，甚至未来几十元即可购得，毕竟它已成为钉钉生态体系中不可或缺的重要组成部分。

与微软Nuance的对比分析

如前所述，A1给我的初始印象其实可以独立于钉钉生态存在，但置于钉钉生态下，其价值则显得尤为独特。

在使用A1的过程中，我第一时间联想到的是微软此前收购的一款产品——Nuance（2022年以970亿美元收购）：

在国内，与之功能类似的产品包括左手医生开发的听诊机器人：

Nuance在AI技术加持下，在医疗问诊环节展现出巨大的想象空间。它能有效协助医生工作，降低误诊率，同时减轻医生在处理文书类工作时的压力。

根据微软发布的相关数据，Nuance已帮助超过600家医疗机构的医生，平均每次问诊节省约5分钟时间，超过70%的临床医生反馈因使用该AI工具而减轻了职业倦怠感，整体产品口碑颇为良好。

然而，尽管Nuance估值很高，但由于数据安全与合规考量，其产品并未在国内广泛落地。而国内一些类似设备往往体积庞大、成本较高，不利于大规模部署，因此近年来在医疗场景中，成熟的语音交互设备仍较为少见。

正因如此，当看到钉钉A1时，我便自然联想起之前的医疗业务场景。从逻辑上讲，A1具备平替潜力，但这不仅需要在应用层进行针对性改造，也对硬件在嘈杂环境下实现精准的多人语音识别能力提出了更高要求。

目前看来，钉钉依然聚焦于办公场景发力。从各类宣传口径来看，A1被明确界定为**“随身办公AI”**，旨在通过轻量硬件结合云端大模型，为职场中的多元角色赋能。

这无疑是合理的策略，因为不同领域的知识在进行语义识别时存在专业门槛。例如，Nuance在医疗领域的优势源于其多年的专业语料积累和算法优化，能够精准识别医学术语和医生的口述习惯，并支持个性化的模板与术语库。

A1若要达到类似水平，不仅需要大量底层基础设施支撑，也需要先在办公场景完成验证与迭代，进而将此类能力以接口形式开放给更多行业与企业。

颇具潜力的是，从现有布局看，阿里巴巴集团似乎确实具备实现这一切的综合能力。

阿里技术栈如何赋能A1平台

阿里生态之所以能够支撑A1从“功能硬件”跃升为“开放平台”，关键在于其形成了完整的技术闭环，这是大多数单一硬件厂商或纯软件服务商难以复制的优势。

阿里巴巴拥有从底层算力（如含光芯片、平头哥半导体）、云计算基础设施（阿里云），到中间层算法（达摩院多模态大模型、语音识别引擎），再到上层应用（钉钉、天猫精灵等）的全栈技术布局。

这意味着A1的语音处理流程可以得到深度优化与定制！

以近期颇受关注的医疗AI产品为例：蚂蚁阿福，其月活跃用户已超过1500万，每日处理健康咨询问题超500万次。虽然这主要面向消费者市场，但未来未必不能向专业领域延伸，毕竟平台已积累了海量的用户健康数据。

总而言之，钉钉A1及其背后的开放平台构想确实充满想象空间，但市场竞争态势同样不容忽视。

语音AI的未来展望与挑战

除了钉钉A1与微软Nuance，当前语音AI的主流形态大致可分为两条路线：办公效率提升型与消费生活助理型。

在国内市场，科大讯飞的听见产品及智能办公本代表了会议生产力路线：以高精度语音转写为技术底座，叠加说话人分离、智能纪要/待办事项/思维导图等结构化输出功能，并强化私有化部署与数据加密能力，着力解决政府、企业及涉密场景中“能用且敢用”的核心问题。

值得注意的是，讯飞在该领域实力雄厚，仅就说话人分离技术的成熟度便需要长期积累。

当然，这个赛道上巨头云集，包括钉钉、腾讯会议、飞书等均在此布局。

在消费端，家庭物联网入口的路线则较为清晰：即通过结合语音交互、人工智能与智能家电，构建一体化的“家庭管家”生态。这类需求虽非刚需，但随着技术普及和消费升级，其市场存在必然性，可视为高端消费场景的延伸。

最后需要指出，语音类AI产品乃至开放平台拥有广阔的发展前景，对于底层基座模型而言，这也是其多模态能力的重要延伸。

然而，此类产品要真正站稳脚跟，仍需跨越几道关键门槛：嘈杂环境下的多人语音分离与识别精度、企业级数据安全与合规要求、以及针对不同行业术语与工作流程的深度适配能力。

办公场景作为一个高价值且相对标准的起点，钉钉A1做出了不错的尝试。下一步，能否将其核心能力开放给生态伙伴，让更多企业“在其基础上玩出花样”，将是决定该平台发展上限的核心因素。

如果说过去的语音产品竞争焦点是识别准确率，那么未来的比拼将转向：谁能将语音真正转化为生产力工具，谁能将生产力工具进一步平台化、生态化。 AI语音的故事，或许才刚刚拉开序幕……

关于Skills的定义，我们在之前的文章中已有过详细介绍。它是Anthropic为其Claude模型引入的一种创新机制，本质上可以被理解为一组预先封装好的技能模块。

每个技能模块通常包含三个核心组成部分：详细的说明文档、可执行的脚本指令以及相关的资源文件。当Claude模型需要处理特定任务时，它会动态加载对应的技能包，以此来显著提升模型在该任务上的处理一致性和整体性能表现。

与传统的一次性、全量提示注入方式不同，Skills采用了一种按需、逐步迭代的加载策略。具体流程是：当用户提出请求后，Claude模型会首先扫描其所有可用的技能库，依据请求的语义进行智能匹配，自动选出最相关的技能，随后仅将完成任务所必需的指令和资源加载到当前上下文中。这一动态决策过程可以通过以下示意图清晰展示：

总而言之，Skills从实际工程实践的角度出发，显著缓解了传统AI Agent在工具调用方面面临的几个核心痛点：

一、工具调用准确性的显著提升

传统的AI Agent方案，如果缺乏工程层面的主动优化设计，通常会选择一次性向模型注册大量的工具接口。这种做法容易导致模型混淆名称或参数相似的不同工具，进而引发工具调用错误。

Skills机制通过引入语义过滤和专用技能包的概念，使得模型在每次执行任务时，只需要关注与当前任务强相关的少数几个工具或指令，从源头上减少了歧义产生的可能性。其直接结果是，整个工具调用过程的准确率得到了有效提升。

当然，当技能包的数量积累到一定程度后，其中必然会出现功能相似的Skill。此时，传统方案中困扰开发者的工具意图识别问题，仍然有可能在新的层面重现。

二、任务流程的一致性保障

每一个Skill都以一套明确的标准作业程序来定义任务的执行步骤和内部逻辑，强制模型按照既定的流程逐步操作，从而减少了因其自由发挥而带来的结果偏差。这实质上等同于将工作流的逻辑从传统的代码实现，转移到了提示词或Skill的定义之中。

Skill内部的指令通常包含对多轮交互步骤的拆解、错误检查的节点以及关键决策的条件判断。这种结构化的流程设计使得复杂任务的执行变得更加可靠。

同时，Skills还能通过上下文隔离机制来增强系统的稳健性：不同的Skill各司其职，彼此独立运行。这意味着，某个Skill内部产生的错误或异常，不容易“传染”并影响到整个对话流程的后续部分。

三、提示词工程的可维护性增强

在过去，提示词的无节制膨胀是一个令人烦恼的工程难题。引入Skills机制后，开发者不再需要将所有可能的指令、规则和知识预先写入一个庞大而臃肿的系统提示词中。

取而代之的是，开发者可以将不同领域的知识和业务流程按照具体场景拆分成独立的Skill模块。这些Skill仅在相关任务被触发时才被动态加载。这种模块化、按需加载的设计思想，不仅节省了宝贵的上下文窗口长度，更使得提示词的长期维护变得简单高效。当需要新增或修改某项业务流程时，开发者只需更新对应的Skill定义文件即可，无需在繁杂的代码中四处搜寻和修改散落的提示词片段。

与第二点相似，如果Skill的数量增长过多，这种模块化方案本身也可能催生新的工程管理和维护挑战。

综合以上三点可以看出：Skills通过 “封装标准流程+按需动态加载” 的工程化方式，使得AI Agent在使用工具时更加精准可靠，同时也降低了长期的维护成本。

然而，如前所述，如果Skill数量过多，依然会衍生出新的维护难题；另一方面，当前许多主流模型并不原生支持Skills机制。因此，我们今天将通过简单的代码模拟来实现一个类似机制，以便更清晰地阐明两点：

1. Skills本质上是一种针对AI Agent的工程化优化策略。
2. 为何Skill数量过多后，依旧会产生新的工程维护问题。

OpenAI模型如何使用Skills

Claude Skills所带来的体验提升，主要源于三件工程化的事情：

1. 技能资产化： 将标准作业程序、业务规则、对话话术等从散乱分布的Prompt中剥离出来，形成可进行版本管理的文件资产。
2. 先路由后加载： 首先将用户请求路由到最相关的Skill，再将这个特定Skill的指令加载进当前上下文。
3. 在Skill内部约束工具使用： 强制模型按照Skill内定义的标准程序来调用工具，减少工具的误调用、漏调用及调用顺序错误。

如果要在其他模型上自行实现一个简易的Skills机制，至少需要考量上述几个核心场景。

一、如何定义Skills

其核心结构设计遵循以下标准模式：

skills/  
  expense_reimbursement/  
    skill.json  
    instructions.md  
    examples.md        # 可选，示例对话  
    validators.py      # 可选，用于结果校验或提供兜底逻辑

其中，skill.json 文件用于技能的路由与管理，其内容可能如下：

{  
  "name": "expense_reimbursement",  
  "version": "1.2.0",  
  "description": "查询员工差旅/报销数据，支持按项目维度进行拆分，并输出符合财务口径的总结报告。",  
  "tools": ["get_employee_info", "query_reimbursements", "analyze_reimbursement_data"],  
  "owner": "finance-ai-team",  
  "risk_level": "internal"  
}

instructions.md 是Skill的核心，它定义了标准作业程序以及工具使用说明：

## 触发条件
当用户提问涉及“报销”、“差旅费用”、“按项目拆分”或“财务口径”等关键词时触发此技能。

## 执行步骤
1.  解析用户请求，明确目标员工信息与时间范围（若信息不足，则主动向用户追问补全）。
2.  调用工具 `get_employee_info` 获取员工基础信息。
3.  调用工具 `query_reimbursements` 查询指定时间内的报销记录。
4.  若用户明确要求按项目拆分，则调用工具 `analyze_reimbursement_data(group_by="project")`。
5.  按照既定格式输出结果：一句总结性结论 + 关键数据列表 + 必要的风险提示。

至此，我们已经完成了“将工作流从代码迁移到Skill定义中”的关键一步。在基本配置整理完毕后，接下来需要构思全局的架构设计。

12月23日，继8月的“蕨”版本发布会之后，钉钉在年终之际带来了产品发布会1.1，代号“木兰”。相较于前序版本，此次发布会聚焦于更纵深的AI能力部署。

本次发布会的核心，是钉钉正式推出了全球首个专为AI设计的工作智能操作系统——Agent OS。在发布过程中，钉钉CEO无招一口气展示了超过20款AI新产品，包括DingTalk Real、企业级Agent OS、AI发现、悟空Agent、AI印、AI招聘Agent、钉钉A1等一系列新工具与新概念。

繁多的新品令人应接不暇。然而，对于AI行业的观察者与实践者而言，我们不应仅仅停留在看热闹的层面，更需要穿透表象，探究其本质。例如，钉钉此次重点展示的几款**“AI叠加硬件”的产品**，如钉钉A1和DingTalk Real，它们的战略意图究竟是什么？

如果说1.0“蕨”版本的核心是围绕“AI表格”展开，那么1.1“木兰”版本的核心主题又是什么？或许下面这张图能够提供线索。

尽管Agent OS的愿景宏大且极具吸引力，但其成熟与普及尚需时日。真正引发我深入思考的，是DingTalk Real与钉钉A1结合所带来的 “信息通道建设” 理念。这恰恰触及了我去年一个AI To B创业失败项目的核心痛点——我们当时的产品名为“CEO数字分身”。

一、从CEO数字分身看数据收集难题

去年，我们构想并开发了“CEO数字分身”产品。其初衷是希望利用AI强大的分析与总结能力，充分挖掘和利用公司内部既有的信息资产。在理想状态下，只要数据足够完备，AI便能成为卓越的决策辅助。

然而，美好的构想在实践中遭遇了巨大阻力。我们发现，最大的障碍并非系统架构设计或数据分析算法，而是我们根本无法有效获取公司内部那些分散、零碎的数据。数据收集本身，成了整个系统构建中最艰难、最核心的环节。

为了推动产品形成最小闭环，我们不得不退而求其次，转而构建一套以“日报”为核心交互机制的系统。这套系统的本质，其实更接近于AI驱动的项目管理工具。

我们的目的非常明确：通过项目管理流程，以产品经理驱动员工撰写日报、整合各类CRM数据等方式，将公司内部分散的信息强制性地归集起来。我们确实也搭建起了一个初步的框架。

随之而来的问题却更为棘手：系统研发成本高昂，各子系统间需要复杂的对接与打通。即便系统成功开发出来，在企业内部的推行与应用也异常困难，阻力重重。

我们也曾构思过一些颇具野心的策略，例如开发一个全局AI机器人，试图从钉钉、微信等各类即时通讯工具中自动抓取和解析工作相关的消息流，让数据收集过程变得无感且全面。然而，这显然超出了我们这类初创团队的能力与资源边界。最终，这个项目只能遗憾搁置。

而我无法做到、不擅长解决的事情，恰恰是像钉钉这样拥有独立IM（即时通讯）生态的团队所天生擅长的领域。

因此，如果要问我对钉钉1.1产品体系生态规划的理解，我认为钉钉正在系统地构建一种收集与利用企业零散数据的工作新范式。因为只有当数据被高效、结构化地收集起来之后，AI的能力才能得到真正的释放。AI在企业中发挥价值的基石，正是完备、流畅的数据通道。而钉钉，正在全力构建这条通道。

那么，为什么说这条路是正确的呢？我们需要从更宏观的视角来审视。

二、信息与战略：AI如何重塑决策

首先，对于任何一家公司而言，最核心的任务是制定正确的战略与精准的目标。而优质战略的底色，来源于充分的信息输入与阅读。我们通常所说的创新，在很大程度上来讲，也是在足够信息输入基础上进行的有效排列组合。这种排列组合的目的，在于发现更优的解决方案、新的方法或商业模式。因此，对内外部信息的系统化整理，在此过程中至关重要。

以任何公司都可能经历的产品与市场信息交互、产品迭代过程为例：

在过去，收集和分析这些信息往往需要一个被称为“战略部”的专门团队。而在AI时代，这个职能很可能被一套 “AI + 方法论” 的新型工具所部分替代或增强。其逻辑并不复杂：

公司需要投入资源，建立并维护一个动态的外部信息渠道库，持续吸收外部环境的变化。这个信息库应涵盖竞品公司动态、行业专家观点、监管政策动向、技术前沿突破等多个维度。

这些信息首先能帮助我们从新的角度审视老问题，寻找不同的解法；其次，它能让我们看到其他领域更专业的做法，进而思考“这件事能否用AI重做一遍”。

构建这样一个外部信息库，其核心可归纳为三点：

1. 定义信息渠道：明确公司需要关注哪些具体的信息来源。
2. 规范获取方式：针对不同渠道（如新闻、财报、社交动态、专利库），设计自动或半自动的信息抓取与清洗流程，并统一输入格式。
3. 设计输出与应用：思考信息结构化之后如何服务于决策。简单入库只是第一步，更重要的是如何让这些信息能被AI或决策者方便地调用与分析。

以竞品分析为例，需要系统化关注的信息可包括：

1. 产品更新：最新功能发布、技术参数、用户反馈、产品生命周期与升级路线图、成本与供应链情况。
2. 市场策略：营销活动（广告、社交媒体）、定价模型、渠道布局（线上、线下、代理）。
3. 合作关系：核心供应商与合作伙伴动态、大客户案例、跨界合作动向等。

以往，我们可能需要自建一套复杂系统来完成上述工作。而现在，利用钉钉AI表格等工具，可以快速搭建起一个可协作、可分析的信息看板。更重要的是，钉钉一体化的工作流与数据处理能力，能让这些信息的收集、流转与分析变得更为顺畅。

总而言之，从当前趋势看，钉钉生态正在系统性地解决企业数据“收”的问题，并通过AI赋能解决“用”的问题。企业数据产生深度价值的时代，正随着这类基础设施的完善而加速到来。

三、结语：AI时代的工作范式变革

传统企业管理面临的一大核心难题在于客观评价。由于利益关联，评价往往难以服众，最终容易导致部门墙高筑、战略执行走样。

但在AI时代，评价与信息处理的部分工作可以被AI工具客观、高效地完成。在这一基础上，未来的组织架构可能呈现出新的形态。

我们可以设想，未来企业可能直接依托如钉钉这样的平台化基础设施，实现如下运作模式：

1. 战略生成：持续收集外部信息，结合公司内部状况，由AI辅助生成或分解战略任务。
2. 无损下达：得益于AI与信息通道的深度结合，战略意图与背景信息可以几乎无损地下达到执行层。
3. 智能匹配：AI进一步对复杂任务进行智能化拆分，并基于对员工技能与历史数据的理解，将任务匹配给最合适的人选。
4. 执行与反馈：员工执行任务的过程数据被AI实时收集。若遇到问题，可即时获得来自AI或背后“专家系统”的指导。
5. 复盘与激励：任务完成后，AI可辅助进行项目复盘，并基于客观数据对员工贡献进行即时反馈与激励。

这种模式建立在企业对内外部信息高度透明和流畅利用的基础上。它可能弱化固定的部门概念，让员工围绕任务组建临时团队，通过完成任务积累个人价值。

当然，这套体系极为复杂，其最大的难点在于如何打通与结构化公司内外部所有关键信息流。这在过去几乎是不可能完成的任务，但在钉钉这类集成了IM、OA、应用开发平台和AI能力的生态加持下，正逐渐变为可能。

最后，让我们对本次发布会做一个总结。我认为钉钉1.1发布会表面上在力推Agent OS和众多AI新品，但其真正的战略重心潜藏于底层：它正系统性地解决AI在企业落地中最困难的一环——如何将散落在员工、事务与软硬件中的碎片化信息有效地管理、串联并利用起来，从而塑造一种适应AI时代的新型工作范式。

AI的强大取决于模型，但AI的价值依赖于信息。

没有高质量、持续流动的信息通道，再先进的模型也无用武之地。钉钉1.0展示了AI“能做什么”，而1.1则在回答AI“凭什么能持续做好”——通过“软件工作流+硬件入口+AI收拢”的三位一体，它正在构建企业信息的收集、流转与结构化体系。

在信息泛滥的当代社会，我们每日被碎片化资讯包围，看似不缺知识，实则匮乏对经典内容的深度沉淀与内化。为此，特此遴选十部豆瓣评分9分以上的优秀著作，每一本都经得起时间考验，值得反复咀嚼与回味。

《三千世界》 作者：苏莞雯

豆瓣评分：9.3

这部作品是一部备受赞誉的青少年科幻文学。起初看到它凭借9.3分却只有20条评价时，难免让人怀疑其真实性，但深入阅读后便会发现其过人之处。它隶属于“平行世界”这一经典科幻主题，从进化论的科学角度出发，构建出一个逻辑自洽的世界观。即便不能称之为顶尖杰作，也绝对是一部值得细细品味的佳作。

《三千世界》系列包含四部作品，分别为《动物都是野心家》《自称王子的土拨鼠》《向天空进发的狗》以及《偷天换日的蜂群》。每个故事都围绕一个动物主角展开，以女主角吕可颂帮助动物回归家园为主线。情节听起来或许充满童趣，但在当下，能以孩童视角书写且情感真挚动人的作品已然稀少。

尽管该作品主要面向少年儿童读者，但成年人翻阅后同样能获得独特的启发与感悟。行文没有复杂艰深的原理阐述，插图里的小动物形象柔和软萌，语言风格也别具一格。无论是赠予孩童还是自行阅读，都颇具价值。

《星际旅行日记》 作者：[波] 斯坦尼斯瓦夫·莱姆

豆瓣评分：9.0

《星际旅行日记》的中文版本由科幻世界杂志社推出，收录于“世界科幻大师丛书”之中。作品以太空旅者伊翁·蒂奇的冒险经历为核心，通过十二篇旅行日记，向读者呈现了大量充满原创性与前瞻性的奇思妙想。作者斯坦尼斯瓦夫·莱姆是国际知名的波兰科幻作家，其想象力天马行空，极具感染力。

该书已被翻译成超过50种语言，全球销量突破4500万册，并入选豆瓣2022年度科幻奇幻图书榜单，获得了刘慈欣、戴锦华、梁文道等多位不同领域作家学者的联袂推荐，想必许多科幻爱好者早已拜读。

早先关注时，这本书的豆瓣评分维持在9分，近期因评价人数增加，分数略微下调至8.9分，但这依然证明了其出众的品质。书中融合了幽默、讽刺、冒险与意外情节，同时穿插着复杂的科学设想与哲学思考，唯有亲身阅读才能领略其魅力所在。

《陶渊明全集》 作者:（晋）陶渊明 集注:（清）陶澍 点校：龚斌

豆瓣评分：9.4

陶渊明其人，大众耳熟能详，但其作品往往仅限于语文课本中的少数诗篇。若想更深入、更真实地理解这位隐逸诗人，直接品读其原作或许比阅读后世传记更为有效。

上海古籍出版社出版的“国学典藏”系列中收录了这本《陶渊明全集》，它汇集了陶渊平生的主要作品，并采用了清代文学大家陶澍的集注，由龚斌进行点校，力求呈现原汁原味的文本风貌。

新中国成立以来，市面上涌现过诸多陶渊明作品集与注释本，如中华书局、山西古籍出版社的版本均口碑上乘，但大多已绝版，读者只能寻觅旧书。在仍在售的相关图书中，这本《陶渊明全集》无疑是一个极佳的选择。

《呼兰河传》 作者：萧红

豆瓣评分：9.3

萧红是民国时期著名的女作家，被誉为“文学洛神”。令人惋惜的是，她年仅三十一岁便与世长辞，临终前完成的《呼兰河传》成为其所有作品中影响最为深远的一部。小学课文《火烧云》正是节选自其中。

呼兰河畔承载着萧红童年的纯真快乐与人生的苍凉感悟。在多年漂泊之后，她于生命尾声回望故土，写就这部充满童心、诗情与灵感的“回忆式”长篇小说。作品运用绘画般的语言，在灰暗的日常背景前，勾勒出粗线条、色彩鲜明且带有原始生命力的图景，再现了一幕幕童趣盎然的往事影像。

尽管时光流逝近百年，《呼兰河传》依然广受读者喜爱，多家出版社都推出过不同版本。个人较为偏爱天津人民出版社的这版，它依据1940年初刊本为底本，原貌呈现萧红文字，封面设计意境深远，与内容高度契合。

《寻找家园》 作者：高尔泰

豆瓣评分：9.5

《寻找家园》的作者高尔泰本是著名画家，写作仅是其身份之一。这部作品记录了他对过往岁月的追忆，通过《梦里家山》和《流沙堕简》两卷，以美学家的视角与灵动的笔触，为读者提供了鲜活的生命纪实。书中没有过多评议，只有真挚的叙事，读来感人至深。

高尔泰用一部书书写一生，这些文字既是历史的真实回溯，亦是对人性深渊的揭示与灵魂深处的挖掘。文笔朴实细腻，凭借客观的叙述与深邃的思考深深吸引着每一位读者。

作为一位美学研究者，高尔泰的作品既蕴含悲壮苍凉之美，又流露沉郁忧伤之情，充满了真挚的情感力量。他对历史细节的刻画使人如临其境，可惜这本书现已停止发行，只能通过电子版或寻找库存旧书来阅读。

《遍地风流》 作者：阿城

豆瓣评分：9.0

《遍地风流》是“阿城文集”丛书中的一册，该丛书还包括《棋王》《常识与通识》《威尼斯日记》《闲话闲说》等。其中《遍地风流》影响力尤为显著，被公认为阿城先生的经典之作，深受读者青睐，出版后屡次再版。

在阿城自己看来，从出生到求学、漂泊、成家、工作、育子的人生轨迹与他人并无二致，写作也不过是将文字投至能刊印的地方，换些钱补贴家用，宛如打零工。因此，他的文字也透着一股闲散之气。莫言曾评价其作品：“你会暂时忘掉人世间的纷乱争斗，即便想起来也会感到很淡漠。”

尽管情绪表达趋于平淡，书中人物也平凡无奇，他们如风、树、牛、马、狗般自然存在于天地之间，看似没有明确立意，但内容刻画却细致入微，不动声色地将世界铺陈眼前。正是这种市井百态，令人深深着迷。

《燕食记》 作者：葛亮

豆瓣评分：9.0

此书曾入选豆瓣2022年度中国文学（小说类）第七名，并荣获CCTV“2022中国好书”奖项，被誉为“三餐惹味处，半步岭南史”。作者葛亮曾是鲁迅文学奖、“亚洲周刊十大小说”及“中国好书奖”得主。

《燕食记》讲述了岭南百年老字号同钦楼传闻将于年底结业，一帮老员工合力盘下店面、奋力挽救危局的故事。小说沿着饮食文化的发展脉络，以师徒二人的传奇身世与技艺传承，见证自辛亥革命以来粤港地区所经历的时代风云变迁。

这部小说虽以岭南为背景，却生动描绘出中国近百年社会变迁与世态人情的宏伟画卷。从岭南饮食风物着手，文字醇熟老练，充满人间烟火气息。连《舌尖上的中国》导演陈晓卿都盛赞其“字里行间，如文火慢煮。落笔包容温暖，又深沉有力。时代在鼎鼐中更迭，既是日常盛宴，也是冷暖人间。”

《诊疗椅上的谎言》 作者：[美] 欧文·亚隆/译者：鲁宓

豆瓣评分：9.2

在普通人眼中，心理专家最擅长洞察人性，正是凭借这种卓越的观察力，他们才能分析他人并进行心理疏导。但谁曾想到，他们同样可能陷入被骗的境地？《诊疗椅上的谎言》便揭示了一个事实：心理咨询师也是凡人，同样拥有人类的普遍情感与人格弱点。

作者欧文·亚隆是斯坦福大学医学院精神病学教授、美国团体心理治疗权威，与维克多·弗兰克和罗洛·梅并称为存在主义治疗的三大代表人物。通过这部心理学通俗读物，他探讨了一个核心问题：当心理专家自身陷入困境时，该如何自我疗愈，又如何负责任地引导来访者？

欧文·亚隆在书中展现了精心设计、环环相扣的编剧技巧，情节结构巧妙严密，跌宕起伏，极具戏剧张力。凭借其深厚的专业背景、充满妙喻与幽默的文笔，以及出人意料的结局，他编织了一个辛辣讽刺的故事，既是对心理医生群体的深度剖析，也为普通人认识自我、正视内心提供了一条路径。

《太白金星有点烦》作者：马伯庸

豆瓣评分：9.0

最初了解马伯庸是通过其作品《古董局中局》，当时觉得故事极为精彩，一周内追完四部。因喜爱这个系列，之后便持续关注他的其他作品，如《两京十五日》《长安十二时辰》《显微镜下的大明》等。但多读几部后感觉并非每个故事都能引人入胜，不过《太白金星有点烦》确实别具特色。

在《太白金星有点烦》中，马伯庸以《西游记》故事为框架，以太白金星李长庚为切入点，重新解构了“西天取经”这一经典叙事。天庭与西天联合推出“西天取经”重大项目，太白金星李长庚受命策划九九八十一难，确保唐僧能平稳走完流程、成功取经成佛。然而，他却被费用报销、工作汇报、人事安排、各路神仙的条子、各地妖怪的隐秘心思等无尽琐事缠身，宛如当代苦命打工人的写照，既魔幻又现实。

马伯庸擅长历史题材创作，其显著风格在于将小故事放大、把小人物刻画得饱满立体，并融入悬疑冲突元素。这使得部分作品极具吸引力，部分则略显冗长。相比之下，《太白金星有点烦》构思新颖，充满讽刺意味的情节往往更易引发读者共鸣。

《星期三的战争》 作者：[美] 加里·施密特