从智能体出发：三种与外界交互的方式

之前我们已经分别介绍了MCP、Function Calling、A2A乃至Claude Skills。但许多读者仍感到困惑。究其原因，可能在于这些孤立的知识点缺乏连贯性。要真正理解它们，或许需要从全局视角和目标出发进行梳理。

追根溯源，这一切仍需从智能体（Agent）开始。因为MCP、Function Calling、A2A这三者与智能体直接相关，属于智能体与外界交互的三种核心方式：

Function Calling：大模型调用外部函数的基础能力

首先是Function Calling。这是一种让大语言模型在推理过程中，能够主动选择并调用外部函数或工具的核心能力：

具体的交互逻辑如下：在对话过程中，大语言模型会根据用户的问题（例如：“今天北京的天气如何？”）判断是否需要调用外部函数。如果需要，模型会输出一个结构化的JSON请求，其中包含了要调用的函数名称和相应的参数。随后，我们的后台程序会基于这个JSON请求执行实际的函数调用：

具体的流程，我们可以直接参考GPT官方的定义示例：

# 这是提供给模型识别的工具定义，并非真正的可执行代码
tools = [{
"type": "function",
"name": "get_weather",
"description": "Retrieves current weather for the given location.",
"parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City and country e.g. Bogotá, Colombia"
      },
      ......
    },
  }
}]

每次调用API时都需要传递tools参数，直接调用GPT接口发起请求：

# 每次调用API时都需要传递tools参数，调用GPT接口发起请求
response = client.responses.create(
    model="gpt-5",
    messages=[...],
    tools=tools  # ← 这个参数每次调用都需要携带
)

由此可以看出，模型具备哪些工具调用能力，完全是由我们预先定义好的。模型会根据用户的输入内容，自主选择使用哪个最合适的工具：

# 用户输入
user_query = "今天北京天气怎么样？"

# 模型会进行如下分析：
# - 用户询问的是"天气" → 匹配到 get_weather 函数的 description 描述
# - 提到了"北京" → 对应 location 参数
# - 最终决定调用 get_weather 函数

需要明确的是，模型本身并不会直接执行工具调用，它只会返回一个结构化的调用指令。这个指令是模型经过专门任务训练后产生的结果：

导读：本文基于Google长达60页的官方白皮书《初创公司技术指南：AI Agents》，将其核心内容系统性地拆解为一个可执行的Agent心智模型。本文避免使用华而不实的新术语，而是聚焦于模型、工具、编排、记忆与训练这几件核心要事，为希望深入了解Agent的初学者提供一份完整、清晰的学习路径。

Google近期发布的这份报告，虽然从其宣传来看意在区别于以往偏理论性的文章，也确实披露了不少实践细节，但总体而言，其提供的具体技巧相对常规。不过，它不失为一份非常优质的Agent入门学习材料。

Agent能力的基础，或者说其对工具进行调用的能力，源自于模型的“函数调用（Function Calling）”功能。而模型识别在何种情境下应该调用特定工具的能力，通常是微调训练的结果。例如，Agent可以调用数据库工具获取客户订单以进行个性化推荐，可以根据用户指令调用邮件API发送电子邮件，甚至可以自动执行金融交易。上述每一个功能都要求模型与外部世界（包括工具和数据）进行交互。简而言之，任何具备自主规划与多步任务执行能力的系统，都可被视为Agent。

Agent架构概览

现代AI Agent通常由四个核心层级构成，其经典架构如下图所示：

一、模型层 这是系统的基础，通常由大型语言模型担任，负责自然语言的理解与生成。在实际生产应用中，往往不会依赖单一模型，可能会采用多种模型组合，甚至会对小型模型进行微调以处理特定简单任务。

二、工具层 这包括了各种外部工具与服务，例如数据库、搜索引擎等API。工具层是Agent感知并作用于外部世界的关键。现阶段，工具调用是Agent真正的核心能力，但工具调用的准确性也是当前Agent架构面临的最大挑战。即使在生产环境中采用技能（Skills）技术与强意图识别，其准确率也大致在90%左右，这预示着整个Agent技术的成熟仍需时日。

三、编排层 这一层堪称Agent的“大脑”，负责协调整个系统的运行。具体职责包括编写提示词、执行推理框架、维护对话状态以及决策何时调用工具。它实现了智能体的计划、推理、决策与反馈循环。用更通俗的话来说，广为人知的ReAct架构便是编排层的具体实现，也是代码的主要组成部分。它主要承担以下工作：

1. 组织历史对话（状态管理）；
2. 决策何时调用模型，何时调用工具；
3. 判断何时结束推理过程；
4. 决定如何构建提示词。 它定义了每一轮循环中语言生成的结构：思考（Thought）、行动（Action）、观察（Observation）。

... → 推理(Thought) → 行动(Action) → 观察(Observation) → ...

ReAct = 推理（Reason） + 行动（Act）：

1. 推理（Reasoning）： 引导大型语言模型思考“为何”以及“如何”执行下一步行动。
2. 行动（Acting）： 指导大型语言模型执行具体行动并与环境进行交互。
3. 循环反馈： 通过观察行动结果来驱动下一轮的推理步骤。

四、记忆层 记忆层包含短期记忆（如当前对话上下文、近期交互记录）和长期记忆（如知识库、历史数据、用户偏好等）。它用于存储和检索与任务相关的信息，以支持多轮对话和知识补充。

严格来说，记忆层的处理是Agent系统中最棘手的问题之一，这本质上就是“上下文工程（Context Engineering）”。其核心挑战在于：如何确保数据能与AI有效交互，并让AI在每次推理时都能获取到最相关的数据。具体可分解为三个层面：

1. 检索的完整性：每次信息检索能否成功获取到对应的数据。
2. 数据的适切性：检索到的数据是否“恰到好处”，既不会信息过载（过多信息会浪费Token并可能干扰模型），也不会信息不足（信息过少则无法解决问题）。
3. 生成的准确性：在检索正确、数据组织合理的前提下，模型的最终输出是否符合预期。

以下是Agent整体交互架构的图示：

概括来说，Agent的执行流程为：用户输入 → 编排层处理 → 模型生成思考 → 决策调用工具或直接输出结果 → 工具执行并获取反馈 → 更新记忆并进入下一轮循环，直至任务完成。在ReAct框架下，Agent会不断重复**思考（Thought）→ 行动（Action）→ 观察（Observation）**的循环，直至得出最终答案。

最后，与单纯的大型语言模型相比，Agent具有以下几个关键区别：

1. 知识来源：模型的知只源于其静态的训练数据，而Agent可以通过工具实时访问外部世界信息，扩展其知识边界。
2. 上下文管理：模型通常仅处理单次推理，缺乏会话记忆；而Agent能够维护完整的交互历史，实现连续的多轮对话。
3. 推理框架：模型的输出往往依赖于单一的提示词；而Agent则内置了认知架构和复杂的推理策略（如思维链、反思框架、思维树等），使其能在编排层中进行循环迭代式的多步推理。

接下来，我们将对Agent的这四个核心组件进行详细展开说明。

编排层与认知架构

编排层是智能体系统的核心控制单元，负责组织信息流并驱动整个推理循环。它模拟了人类处理复杂任务时的认知过程：首先获取信息，然后制定计划，执行行动，再根据反馈调整计划，如此循环往复直至目标达成。一个常见的比喻是“厨师准备复杂菜品”：厨师会根据顾客需求获取食材信息，规划烹饪步骤，然后动手操作，并可能根据试味反馈不断调整方法。

我们之前探讨过，构建一个基础的Agent框架或许并不复杂，但若想实现真正智能化的记忆与上下文管理，则完全是另一回事。

例如，如果你只是想打造一个Agent来执行几个预设的技能，用于完成自媒体选题或在社交平台自动发布内容，这相对简单。然而，如果你期望这个Agent能够随着使用时间的增长而变得更加贴心、更懂你，这就颇具挑战了。它会引出一系列深层问题，比如：Agent如何准确追溯你前天的活动？它又是如何清晰记忆事务的先后顺序而不至于混乱？

要解决上述所有问题，就不得不深入研究Agent的上下文工程。在早期的人工智能开发阶段，这项技术被视为核心机密。而OpenClaw的开源，则为我们清晰地展示了生产级别的记忆系统究竟是如何设计与实现的。

因此，如果你询问OpenClaw最具价值的部分是什么，我会毫不犹豫地建议你深入研读其记忆模块的源代码，这无疑是技术进阶的利器。当然，考虑到大家时间有限，我们今天将共同拆解OpenClaw的记忆模块与上下文工程。

理解上下文工程

许多人一听到上下文，第一反应便是提示词或检索增强生成技术。这种理解虽非全错，但略显片面，就如同将编写几行代码等同于完整的软件工程。

在我看来，上下文工程是一套系统性的方法论，旨在构建、管理与注入与当前任务高度相关的背景信息。简而言之：

上下文工程，就是为大语言模型设计一套高可用、可治理且能长期稳定运行的输入供给系统。

那么，更具体地说，什么是上下文？其本质依然是提示词，它代表模型在当前轮次推理或提示词中所能获取的全部信息总和。

上下文 = 系统提示词
  + 用户输入
  + 历史对话记录
  + 工具调用返回结果
  + 检索获取的内容
  + 长期记忆

所有上述信息经过整合，才构成了模型进行思考、决策并最终输出答案的完整依据。

上下文工程的核心目标

大语言模型存在若干固有短板，而上下文工程正是为弥补这些短板而生的：

应对信息幻觉问题

模型在训练阶段从海量互联网数据中学习了广泛的知识，但若缺乏有效引导，其回答可能流于空泛、不够精确，甚至凭空捏造事实。上下文工程的核心任务之一，便是将模型所不知道的、最新的、或专属的精准信息有效地“喂”给它。

突破长度限制

任何模型都有其固定的Token处理上限，复杂的任务很容易撑满上下文窗口。过长的内容会导致模型注意力分散、抓不住重点，甚至直接引发错误。上下文工程需要做的，就是在有限的预算内，筛选并保留最关键的信息。

解决信息可读性问题

如果输入的信息缺乏逻辑、格式混乱、杂乱无章，模型将难以进行有效解读。上下文工程需要将这些信息整理成模型易于理解的结构化格式。

明确的工程目标

综上，上下文工程需要达成以下目标：

1. 引导与约束模型：通过设定背景、规则和示例，为模型划定明确的思考与输出边界。
2. 提升回答准确性：通过注入最新数据、内部知识库和实时信息，从根源上减少模型产生“幻觉”的可能性。
3. 实现复杂任务分解：将无法单次完成的复杂任务，拆解为多轮对话、思维链或系列工具调用，引导模型逐步推理并最终完成任务。

上下文工程的实现路径

首先，提示词工程是上下文工程最核心与基础的部分。它专注于研究如何运用最精确、最有效的语言来构建提问与指令。

其次是知识检索与注入。对于模型不了解或不擅长的领域，上下文工程会通过RAG等技术手段，先检索出相关信息，再将其与用户问题一同打包提供给模型。

接着是记忆管理。在多轮对话中，系统需要有效过滤无关的历史信息，保留关键记忆节点，防止模型遗忘重要前提或被冗长的历史记录所干扰。

最后是输出格式化。明确要求模型以特定的结构输出结果，例如JSON对象或Markdown表格，以便后续的程序能够自动处理。

这里需要特别区分上下文工程与提示词工程。两者关系密切但层次不同：

• 提示词工程：关注如何优化提问本身，包括指令的设计、格式和具体措辞。
• 上下文工程：关注为模型提供什么样的背景信息，涉及外部知识的筛选、加工和注入流程。

由此可见，两者并非对立，而是上下层协作关系。标准的工作流通常是：

• 上下文工程先行：通过RAG、记忆系统、工具调用等方式，筛选出最相关的背景资料。
• 提示词工程收尾：将这些资料与用户问题，通过精心设计的模板组装起来，最终提交给模型。

为了更直观地理解，我们来看一个真实例子：

用户提问：华为最新的旗舰手机是哪一款，什么价格？
- 上下文工程：从新闻数据库或网页中搜索关于华为最新旗舰手机的型号、发布信息及价格。
- 提示词工程：设计最终模板 → “根据以下资料：{{检索到的上下文}}，请回答用户的问题：{{用户查询}}”

至此，我们对上下文工程的基本概念已有所了解。接下来，我们将深入OpenClaw的具体实现。

OpenClaw的上下文工程架构

OpenClaw的上下文工程采用了清晰的流水线架构。整个提示词的组装过程如同工厂流水线，原始数据从一端输入，经过一系列标准化处理步骤，最终的成品（即完整的提示词）从另一端输出。

从架构解析的角度，可以分为三层：

第一层：资源管理层

此层负责管理所有上下文信息的来源，其核心工作是决策：哪些信息必须保留，哪些可以剔除，以及当信息冲突时如何处理。 信息来源包括：

用户配置
工作区文档（如AGENTS.md、TOOLS.md等）
对话历史记录
可用工具列表
长期记忆内容

第二层：组装层

此层负责将收集到的所有资源，按照预定义的固定格式和顺序进行拼装。 它需要处理：

今年以来，我保持着每日阅读的习惯，涵盖了学术论文、行业报告以及国内外的技术文章。虽然大部分内容可能价值有限，但每周总能发现一两篇颇具启发性的文章，例如今天要讨论的这篇：《How I Won the Enterprise RAG Challenge》。

通读全文后，我认为其内容相当出色。以下是我结合自身实践经验与文章内容的一些总结与思考。

架构全景图

首先，让我们审视该系统的核心架构设计：

一个优秀的RAG系统实际上是一套精密的工作流程，更是一套智能决策系统。它在核心的“检索-生成”链条之上，增加了多个“路由器”和“优化器”模块（对于其必要性，我个人持一定的审视态度）：

1. 路由决策： 系统首先需要判断当前问题应该导向哪个最合适的数据源或处理路径。
2. 检索优化： 在初步获取相关文档片段后，系统需要进一步筛选、排序和精炼，以找出最切题的信息。
3. 生成定制： 最后，系统需要依据问题的具体类型和上下文，采用最具针对性的策略来生成最终答案。

接下来，我们将沿用Ilya文章中提出的“RAG洋葱模型”作为分析框架，从最外层的基础设施开始，逐步深入到核心的智能决策模块：

讨论至此，我们不得不再次回归到最基础的环节：数据准备。

任何RAG系统的最终效果，都高度依赖于输入数据的质量。因此，前文将核心仅仅归于检索和生成链条的观点，我本身便抱有疑问。其内在逻辑很清晰：稍微复杂一些的AI系统，其逻辑是相通的——数据工程的质量直接影响提示词工程的效果，而数据处理的质量又决定了数据工程的上限。所以，如果RAG前期数据处理不到位，无论后期如何进行优化和补足，整体效果都难以达到理想状态。

因此，将非结构化的原始文档（例如WORD、PDF文件）转化为干净、规整且易于检索的文本块，是至关重要的一步……

一、文档解析

文档解析是整个RAG流程的起点，也是最容易出现问题的环节。Ilya尝试了大约二十种不同的解析器后，得出了一个关键结论：不存在一种能够完美无损地解析所有PDF文档的通用解析器。

他遇到了各种各样的棘手难题：有些表格在扫描时被旋转了90度，导致解析后的文字完全混乱；有些图表由文本层和图片层混合构成，难以完整提取；甚至部分报告文件存在字体编码问题，视觉显示正常但复制出来的却是无意义的乱码符号。更极端的情况是，某些文档中的文本竟然使用了凯撒加密，需要特定的解码方式才能正确读取。

最终，他选择以Docling作为基础解析器。 为了应对某些复杂的解析场景，他不得不深入该解析器的源代码进行定制化修改，以确保其能够输出包含丰富元数据的JSON格式，进而生成高质量的Markdown和HTML文档。

这个过程揭示了一个必须正视的现实：在真实的RAG项目中，数据预处理往往消耗超过一半的总工作量，并且需要深厚的领域知识和工程技巧。

一个比较有趣的细节是，由于当时比赛时间紧张，他还利用了GPU来加速解析过程，租用了搭载RTX 4090显卡的云服务器。最终，一万多页共计100份年报的解析任务耗时约40分钟，这充分展现了工程化思维在效率提升上的价值。

然而，在实际的工作场景中，我们通常不建议采用这种“特殊操作”。首先，不建议轻易修改第三方解析器的核心源码，这会给未来的维护和升级带来巨大挑战。其次，若非必要，也不建议过度追求极致的解析速度，因为项目时间往往相对充裕，人为增加技术复杂度会提升系统的移交和协作成本。

在真实的文档处理过程中，你一定会遇到各种意想不到的“奇葩”问题。这里没有捷径可走，唯一的方法就是“逢山开路，遇水搭桥”，一个个地解决这些小问题。 每个独立的问题通常并不复杂，很少会出现耗时两天都无法解决的情况。这里的关键在于尽早发现并暴露问题，而不是掩盖问题。

二、向量化

文档被成功解析后，需要被切割成更小的“块”（chunks）才能存入向量数据库。此处的分块策略变得尤为关键：

为了在检索精度和上下文完整性之间取得平衡，Ilya采用了递归分块法，设置了300个token的块大小，并辅以50个token的重叠区域。这种策略确保了语义单元的完整性，同时避免了因单个块过大而导致关键信息的相似度被稀释的问题。

在系统设计上，他进行了长远规划：为每一份独立的文档（例如每家公司的年报）建立专属的向量数据库。这背后是出于效率的考量：当用户的问题明确指向某一家特定公司时，仅在对应的单个向量库中进行搜索，其准确性和速度都远高于在一个混合了所有公司数据的庞大向量库中进行全局搜索。

这一设计实际上引入了“路由”概念的雏形：在正式执行检索之前，先确定搜索的目标范围。类似的思维策略在国内也有应用，例如树形索引结构也能很好地保持不同语义集合的独立性：

三、检索与重排

检索是RAG系统中的“R”（Retrieval），是整个系统的脉络所在，也是检验前期数据准备工作好坏的核心标准。如果检索器无法找到正确答案，那么后续的所有步骤都将失去意义。

从理论上讲，结合语义搜索（基于向量相似度）和关键词搜索（如BM25）的混合检索策略，应当能够提升检索效果。

但Ilya的实践经验表明，在未对用户查询进行深度优化的情况下，简单的混合检索有时甚至会导致性能下降。这说明，先进的技术需要正确的使用方式与之匹配，否则可能适得其反。

根据过往的经验，这里一个比较实用的技巧是查询重写。事实上，一个健壮的系统应该拥有一份自己预期的问题准入清单，或者说一个简单的“意图识别”模块。如果你没有这样一份清单，说明系统设计可能不够健壮，即使用户重新措辞提问，也未必能检索出正确答案。

检索完成后会得到一个候选文本列表，接下来便是重排技巧的用武之地。Ilya的做法是：

1. 首先通过向量检索初步召回30个相关的文本块。
2. 利用这些文本块的元数据，定位到它们所属的原始页面。
3. 将“用户问题 + 页面完整文本”交给LLM，要求LLM根据该页面内容对回答问题的帮助程度进行打分（0-1分）。
4. 将LLM给出的分数与原始的向量搜索相似度分数进行加权融合，最终筛选出最相关的10个页面。

为了加速重排过程，Ilya让LLM一次同时对三个页面进行评分并返回三个分数。这样，邻近的文本可以互相作为参照，有助于提高评分的一致性和整体处理效率。最终，系统结合向量相似度分数和LLM的评分来计算修正后的相关度，例如设定向量权重为0.3，LLM权重为0.7。

这种方法的好处显而易见：它以一种相对低廉的成本（据称每次查询低于1美分），极大地提升了输入给生成模型的上下文材料质量。只要前期数据质量过硬，经过这样筛选后的上下文，必然能引导模型输出更高质量的答案。

然而，只有在实际采用这种重排策略时，你才会真切地感受到企业决策者（如“老板”）对这部分额外token消耗的在意程度。在很多实际场景中，效果和成本往往难以兼顾，除非在更前端的数据工程层面投入更大的功夫。换句话说：

越是复杂和精细的数据工程处理，往往能支撑起更简化、高效的AI应用工程，最终以更低的成本换取更优的前端用户体验。

四、路由与生成

这一部分是其方法论——RAG洋葱模型最核心的体现，需要大家特别留意。这也是许多大型AI项目背后的架构设计思路，也是我推荐这篇文章的主要原因——它已经勾勒出了这类复杂系统的雏形。这里的核心理念是：

通过智能路由，让每一个问题都能被导向最合适的处理路径。

路由是简化问题复杂性、提升系统效率的最有效手段之一。Ilya的系统中设计了两个关键的路由器：

1. 数据库路由： 根据问题中出现的公司名称，直接将查询路由到该公司对应的专属向量数据库。这个策略看似简单（甚至可以用正则表达式实现），却能将搜索范围从100份文档急剧缩小至1份，带来了检索性能和答案精度的双重显著提升。事实上，前文提到的按页面建立索引的思路也与此异曲同工：

2. 提示词路由： 比赛要求答案必须遵循严格的格式（例如纯数字、布尔值、特定字符串等）。Ilya没有将所有格式规则塞进一个庞大而复杂的通用提示词中，而是为每一种答案类型设计了专用的、高度定制化的提示词模板。系统通过简单的逻辑判断（如if…else）来识别问题所属的类型，然后动态选择并注入最合适的提示词，确保LLM能够清晰无误地理解并遵守特定类型的输出要求。

人工智能模型领域近期再度呈现出活跃态势，各类新模型如雨后春笋般接连涌现。

从GLM-5、MiniMax2.7到小米的MIMO，竞争格局持续刷新。本文将聚焦于“大模型六小虎”阵营中的阶跃星辰，深入评测其最新发布的 Step 3.5 Flash 2603 版本。

阶跃星辰是一家专注于通用大模型研发的AI公司，在业界享有“大模型六小虎”之一的声誉。其中智谱、MiniMax和Kimi这三家同为“小虎”的成员已广为人知。

此前，Step 3.5 Flash版本在openrouter平台上已取得不俗的评分。

观察当前的大模型热度排行榜，Step 3.5 Flash稳定地位列前三甲。

因此，本次评测的核心目的是检验Step 3.5 Flash 2603在真实应用场景中的综合表现。本文将依次在Claude Code、OpenClaw、飞书等多个平台上进行测试，并在每个测试案例前予以说明。

评测主要围绕四个核心场景展开，着重评估模型的执行过程与最终产出质量。

任务一：多步骤数据采集与可视化页面生成

第一个任务在ClaudeCode环境中进行测试。

已将模型切换至 step-3.5-flash 2603，并直接下达一个连续性复合指令：

打开 Boss 直聘、拉勾和智联招聘，搜索最近热门的 AI 相关岗位，结合薪资范围、岗位要求、城市分布和招聘热度，综合筛选 10 个代表性岗位，整理成 Excel 表格，并根据 Excel 表格的信息设计一个可视化 HTML。

该任务看似不复杂，实则是一个典型的多步骤、高综合性任务。它并非简单的问答，而是要求模型连贯地完成：联网检索信息 → 归纳总结内容 → 生成结构表格 → 编写前端代码。

这既检验了模型的信息整合与结构化能力，也对其工具调用、上下文维持及连续任务执行能力提出了较高要求。

Step 3.5 Flash 2603在此类任务中表现出高效的节奏感，避免了过度思考与迟迟不落地的拖沓。它采用了边执行边推进的策略，最终一次性交付了Excel表格与信息图HTML代码。

在ClaudeCode中可清晰观察到其执行流程，整个过程显得干净利落。

除了少数设有反爬机制的网站外，大多数任务步骤都能在数秒内完成一轮推进。

以下是最终产出结果。

可视化HTML页面效果

数据表格成果

生成的表格观感良好，信息整理得较为规整，阅读压力较小。HTML信息图也并非简单的内容堆砌，而是尝试进行了层级划分与视觉设计。当然，若在提示词中进一步细化版式偏好、图表样式或字段要求，模型的产出自然会更加精准。

综合来看，对于此类链路稍长的工作流任务，Step 3.5 Flash 2603在保持高效执行的同时，能够可靠地完成任务目标。从本案例可知，阶跃星辰的这版模型在处理高频、多步骤、结果导向明确的任务时，确实得心应手。

任务二：数据库表结构到Java实体类的快速转换

第二个任务聚焦于AI编码中的一个高频场景：数据库结构转换。

对于后端开发者而言，在项目初期或接手现有业务时，首要步骤往往是处理数据库。面对大量数据表，手动将其逐一转换为Java实体类耗时费力。因此，本次测试直接将数据库SQL语句抛给模型，要求其进行批量转换。

这是一个源自RAG客服生产业务的实际数据库表结构。

转换结果直接明了：耗时约一分钟，11张表全部成功转换为对应的Java实体类。

在此场景下，Step 3.5 Flash 2603的体验颇为舒适。需要补充的字段基本都能准确补全，结构转换也相当规整，没有出现编码风格飘忽不定或命名混乱的问题。

既然表结构已生成，便顺势进行下一步，要求模型补充生成部分基础的增删改查（CRUD）代码。

为了访问公司内部仅限特定IP地址访问的网站，部署一台VPN服务器作为固定出口是一个有效的解决方案。尽管网络上存在大量复杂的OpenVPN配置教程，但实际上借助Docker容器技术，部署最新版OpenVPN的过程可以变得非常简单快捷！

应用场景概述

• 需要固定出口IP以访问内部网络资源。
• 本地开发调试时，需接入设置了IP白名单的第三方接口。
• 实现远程且安全地访问公司内网的各类服务与资源。

部署环境准备与配置

在开始部署前，请确保您的服务器环境满足以下要求：

第一步：安装与配置OpenVPN服务

1.1 通过宝塔面板搜索并安装OpenVPN镜像

登录宝塔面板，进入“Docker”应用，在镜像仓库中搜索“openvpn”，选择由 kylemanna 维护的 openvpn 镜像进行拉取和容器创建。安装过程通常会自动生成初始配置。

1.2 优化客户端配置文件

安装完成后，在指定的数据卷路径中找到自动生成的 .ovpn 客户端配置文件。为了提高兼容性并避免某些连接问题，建议在配置文件中添加以下指令以禁用压缩：

comp-lzo no

此配置通常添加在 remote-cert-tls server 行的下方。

关键提示：配置文件修改并保存后，即可将其下载到本地，供OpenVPN客户端软件导入使用。

第二步：配置客户端并进行连接

2.1 在Windows系统上连接VPN

1. 在本地计算机安装并运行 OpenVPN GUI 客户端。
2. 找到系统托盘区的OpenVPN图标，右键点击。
3. 选择菜单中的 【导入文件】 选项。
4. 导入上一步下载的 .ovpn 配置文件。
5. 导入成功后，再次右键托盘图标，点击 【连接】。

2.2 验证连接状态

• 连接成功标志：系统托盘中的OpenVPN图标变为绿色，并且通常会显示已分配的虚拟IP地址。
• 连接失败排查：如果无法连接，请按顺序检查以下设置：
  • 云服务提供商的安全组规则是否允许入站 UDP 1194 端口。
  • 宝塔面板的“安全”页面中是否已放行 1194 端口。

2026年无疑是智能体应用爆发的一年。为了帮助大家更好地掌握智能体落地的关键技术，本系列文章将持续更新。今天的重点，是程序员群体中最常用的智能体开发框架——LangChain。

不过，随着AI编程工具的成熟，这类框架的文档可能逐渐从“给人看”演变为“给AI看”。

LangChain既指一个开源的AI应用开发框架，也指其背后的同名公司。该公司围绕AI应用开发生态，构建了完整的产品矩阵，包括广受欢迎的开源框架LangChain、用于构建复杂状态机的LangGraph，以及企业级的调试与监控平台LangSmith等。其中，LangChain和LangGraph是社区中最为活跃的两个开源项目。

需要特别指出的是，在LangChain演进到1.0版本之后，这两个框架的定位发生了显著变化：LangGraph成为底层的智能体编排引擎，专注于有状态、多轮次、高度定制化的智能体流程控制；而LangChain则演变为上层的应用开发框架，提供了更高阶的抽象、丰富的工具集成和便捷的智能体构建能力。

简而言之，LangChain封装了LangGraph的复杂性，让开发者能够快速搭建标准化的智能体；而LangGraph则为那些需要深度控制流程、实现自定义逻辑的场景，提供了灵活的图式编程能力。

对于大多数智能体应用场景，例如本文将要构建的旅行规划助手，使用LangChain已经足够。它简洁的API和开箱即用的组件，能让我们更专注于业务逻辑本身。

请注意，本文基于LangChain版本>=1.0。此外，虽然案例简单，但建议与同系列的前几篇文章对照阅读，以便深入理解智能体的本质与LangChain框架的设计意义。

如何开发一个Agent

为了兼顾不同的表达习惯，下文将交替使用“Agent”和“智能体”两个术语。

如之前文章所述，开发智能体的核心可以归结为三要素：模型（Model）、工具（Tools）和记忆（Memory）。

1. 模型负责核心的推理与决策。
2. 工具用于执行具体的业务操作（如查询天气、搜索信息）。
3. 记忆负责保存历史对话，为模型的推理提供充足的上下文支持。

如果您对AI Agent的概念或开发流程尚不熟悉，建议先回顾本系列的前置文章。

接下来，我们将通过实际操作，展示如何利用LangChain实现模型调用、工具封装与会话记忆，从而完整地开发出一个可运行的AI智能体。

模型调用

LangChain提供了标准化的方法来集成各大厂商的模型，官网给出了完整的支持列表。我们可以访问其文档页面，查看具体模型的使用方式。这里我们以DeepSeek为例进行说明。

上图展示了LangChain为DeepSeek模型提供的专用集成包，可以直接安装使用：

from langchain_deepseek import ChatDeepSeek
model = ChatDeepSeek(
    model="...",
    temperature=0,
    max_tokens=None,
    timeout=None,
    max_retries=2,
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    # 其他参数...
)

其他模型提供商也有对应的集成包。此外，您也可以使用OpenAI的标准格式，目前绝大多数模型都兼容这种调用方式：

model = ChatOpenAI(
  model="deepseek-chat",
  api_key=os.getenv("DEEPSEEK_API_KEY"),
  base_url="https://api.deepseek.com",
  temperature=0.7
)

通过上述方法得到模型实例后，即可使用invoke或stream方法向其发起请求并获取响应：

model = ChatOpenAI(
        model="deepseek-chat",
        api_key=os.getenv("DEEPSEEK_API_KEY"),
        base_url="https://api.deepseek.com",
        temperature=0.7
    )

    messages = [
        {"role": "system", "content": "你是一个有用的助手。"},
        {"role": "user", "content": "你是谁"}
    ]

result = model.invoke(messages)
print(result.content)
# 流式输出
result = model.stream(messages)
for chunk in result:
    print(chunk.content)

声明工具

在LangChain中定义工具函数非常简单，使用@tool装饰器是最常用、最便捷的方式：

在日常生活中，您通常如何寻找免费的电子书资源呢？事实上，许多流通的免费电子书可能涉及盗版内容。阅读本身是一种高尚的精神活动，因此我们强烈建议读者尽可能支持正版书籍。值得欣喜的是，支持正版很多时候并不需要直接付费，而是可以通过合法渠道获取丰富资源。

今天，我们将详细介绍一个由官方推出的数字图书馆——首都图书馆电子资源平台。该平台提供完全免费的阅读服务，涵盖133万册电子书、1.5万册有声读物、1500种期刊、50余种报纸、795.8万篇学术论文以及超过5000部视频资料。

此外，平台还拥有大量双语绘本资源，这尤其适合家中有孩子的父母。接下来，我们将逐步说明如何获取并使用这些免费资源，建议您收藏本文以备后续参考。

首都图书馆的官方网站很容易找到，直接通过搜索引擎即可访问。首先，请在浏览器中打开首都图书馆的官网页面。

进入官网后，注意页面右上角有一个小人形状的图标，点击该图标即可进入登录界面。

在登录框中输入读者卡号、密码及验证码，即可使用站内所有资源。但这里存在一个常见问题：网页端未提供新用户注册入口。那么，新用户该如何获得平台电子书资源呢？

针对新用户，需要先通过移动端完成注册。请打开微信，搜索并进入“首都图书馆”小程序，点击右下角的“我的”按钮，然后选择页面上方的“绑定读者卡”。接着点击“快速注册”选项，填写个人基本信息即可成功申请读者账户。

完成注册后，返回电脑端的登录界面，输入刚才申请的读者卡账号和密码进行登录。

登录成功后，点击页面上方的“资源”栏目，然后选择您感兴趣的类别。如果您身处外地，可以直接点击“馆外访问”选项以使用相关资源。

筛选后，页面将显示所有支持馆外访问的资源库。首都图书馆接入了众多第三方资源库，点击任一资源库的“馆外访问”链接后，系统可能会要求再次输入首图账号密码以验证身份。

如果您需要为孩子寻找绘本资源，可以点击“少儿”分类。目前支持馆外访问的少儿资源库包括书童AR互动科普教育资源库、新东方双语阅读平台以及中少快乐阅读平台。

书童AR互动科普教育资源库以虚拟展馆的形式呈现内容，用户可以直接搜索或选择不同主题进行浏览学习。

新东方双语阅读平台的内容非常全面，提供中文绘本、英文绘本、趣听绘本等多种类型，资源格式涵盖图书、音频和视频。

每本图书通常分为四个学习板块：绘本阅读、名师精讲、跟读训练和趣味练习，旨在提供多维度的学习体验。

以上展示的仅是首都图书馆电子资源的冰山一角。事实上，全年龄段读者都能在这里找到所需或感兴趣的内容，无论是期刊杂志、学术论文还是文学小说，各类阅读需求均可满足。

最后需要提醒的是，通过首都图书馆界面跳转至第三方资源库时，可能需要重新输入账号进行验证。请务必使用首都图书馆的读者证账号，不要输入错误信息，也不要因为需要重复登录而放弃使用。

从事AI咨询服务的同行们或许都深有体会：面向研发技术团队的咨询服务往往是最具挑战性的！ 这背后的原因究竟是什么呢？

核心问题在于，团队常常处于“半瓶水响叮当”的尴尬状态。你会遇到那种似乎懂一些，却又理解不深，并且带着质疑与审视的“甲方”眼光，看你不断“表演”（输出）的团队。在这种情境下，无论你如何努力，效果通常都不会理想，因为他们往往只愿意听取自己内心已经认可的那部分观点。这正是知识型咨询服务中最棘手的场景：

1. 你需要将知识有效地植入他人的思维；
2. 同时，你需要将他人钱包里的钱合理合法地装入自己的口袋。

一旦遭遇这种场景，咨询项目很容易折损口碑。而如何在这样注定会损耗口碑的局面中，最大程度地挽回损失，甚至确保不产生负面影响，就成了一门需要高超技巧的艺术。

回顾过去两年的实践，我累计与超过五十家公司进行过交流，其中产生付费行为的有二十余家。在这些合作中，不可避免地需要直接面对产品与研发团队，一系列的故事便由此展开。我们首先需要深入思考一个根本性问题：AI咨询究竟交付的是什么？

AI咨询的核心交付物是什么？

首先，关于“交付”的理解，需要从两个视角来看。对于寻求咨询的企业而言，他们的核心期待是：在有限的时间内，获得一套相对完整的解决方案设计。这套方案可能涵盖：

1. 技术架构的设计；
2. 技术框架的选型建议；
3. 团队搭建的组织架构设计；
4. 项目如何包装“AI故事”以获得资源支持；
5. 具体技术卡点的处理方案；

这样的描述可能略显抽象，让我举几个具体的案例来说明企业通常会提出的问题：

1. 商业落地节奏与AI技术的迭代节奏难以协调，该怎么办？
2. 智能体（Agent）之间的协作逻辑复杂，状态管理困难，应如何解决？
3. 如何平衡模型精度、算力成本与内容安全合规要求？
4. 如何应对提示词（Prompt）膨胀带来的工程化维护难题？
5. 是否有必要为每一个Agent都建立独立的记忆模块？
6. ……

客观地说，这些问题本身并非没有价值。但关键在于，许多问题的提出方式往往“不接地气”。例如，关于多Agent系统中是否为每个Agent建立记忆模块的问题，这本身是一个颇具深度的技术架构议题。然而，实际情况可能是，提问的团队其生产环境中根本就没有真正需要多Agent复杂协作的场景。

于是，一个根本性的矛盾就凸显出来：团队实际项目的技术难度可能是3分，却选择了一个复杂度为5分的技术架构；同时，团队自身的技术能力只有2分，却提出了大量自己都无法完全理解的问题。

如果我们将他们 “自以为需要解答的问题” 真正展开，又会发现情况复杂：有的问题过于宏大，例如如何系统性地平衡商业节奏与研发节奏；而有的问题又过于微观和具体，例如“我写的某个具体提示词总是无法准确提取关键词，请你帮我调试看看”。

类似这样的情况，对于我们咨询方而言是非常棘手的。因为过于宏大的问题无法在三言两语间说清楚，它必须深入公司的具体业务体系，再结合AI技术的特性进行定制化方案设计，这个过程没有一两个月的时间投入很难完成。而那些过于微小和具体的问题，则可能具体到需要跟着程序员一行行调试代码。如果我们陷入这种细节，同样无法从根本上解决问题。

那么，作为咨询方，我们应该如何应对呢？这就需要我们从咨询师的角度出发，构建一套行之有效的策略。

一、交付有效的方法论

对我们而言，几乎所有的应用层AI项目类型都已有过实践或深度的研究。因此，对于不同类型项目的执行方法论，我们必须有非常清晰的认识。如图所示：

以“工作流AI”项目为例，其核心方法论可以精炼为一句话：“先看预算再拆分，能用AI则用AI”。这句简单的话展开后，就会形成如下图所示的具体工作路径：

将这套方法论展开，便是一套完整的工作流程：

1. 梳理并列出完整的业务流程所有环节。
2. 识别哪些环节由人工参与，并评估其人力成本。
3. 分析每个环节是否能用AI替代，如果可行，需要依赖什么资源，成本是多少。
4. 最终，标出所有可以用AI实现的环节，并说明完整实现所需的总体成本。
5. ……

这类工作的核心在于梳理标准作业程序（SOP）。而衡量一个AI产品成功与否的关键，是看它能否完整替代人工，或者能在多大程度上提升效率、降低成本。

交付一套清晰的方法论，无论对企业还是对咨询师而言，都是最优解。然而，这一目标的达成往往困难重重，因为双方很难实现“同频对话”。究其原因，多数企业在启动咨询前，自身并未做好充分准备。

认清现实：咨询无法解决管理问题

在我们观察过的众多公司AI项目中，那些执行得比较顺利的项目都有一个共同特点：拥有一位强有力的“一号位”推动者，很多时候这个人就是公司的CEO。

这带来的好处是显而易见的。团队中至少有两人（可能是CEO、技术接口人、业务接口人或产品接口人）对项目的全局有非常清晰的认知。一个有力的证明是：在我们的辅助下，他们能够迅速绘制出项目的业务全景图。

这张全景图可能长这样（与上文提到的HR业务中台示例类似）：

事实上，只要能够共同梳理并形成这样一张图，整个项目80%的问题就已经有了解决思路。但就我所服务的许多产研团队而言，他们往往很难独立整理出这样的全景图，因为他们可能缺乏相应的业务视野或跨部门协调能力。

这时或许有读者会提出：既然产研团队没有这个视野，那就去找具备这种视野、能画出全景图的人啊！

当然可以，事实上我们每次都会尝试这样做。通常，这个角色是公司副总裁（VP）级别的业务负责人。你说他懂业务吗？当然懂。但他能不能把业务给我们（咨询方）讲明白呢？往往很难。那么问题来了：为什么讲不明白（无法清晰说明业务）？

答案可能有些扎心：多半是他不愿意（或没动力）进行如此深度的共享。 这也是咨询过程中极易遭遇的一个困局：“企业接口人的礼貌性回应”。什么是礼貌性回应？举个例子：

如果你现在问我：“Agent是什么？” 礼貌性的回答可能是：“Agent是一种具备自主感知、规划、决策和执行能力的AI系统，它能够调用外部工具与接口来解决实际问题。”

这种听起来好像回答了，但又感觉什么都没彻底说清楚的表达，往往就属于礼貌性回应。此时你可以继续追问：“请问它具体包含哪些核心模块呢？”

我可能依旧会礼貌性地回答：“通常包含任务编排、工具调用、记忆管理等模块。您还有其他问题吗？” …… 相信我，用不了几个回合，你自己就会感到无从问起，沟通难以深入。

而那些真正想要解决问题的人，他们会主动拿着初步梳理好的材料或框架，追着你进行探讨。例如，之前有一家公司，单个负责人确实没有能力梳理出完整的业务全景图。于是，他们组织了一次为期三天的封闭会议，将所有相关的管理者和关键节点负责人聚集在一起，硬是共同协作，将全景图梳理了出来。

综上所述，只要企业方的关键决策者或接口人不是发自内心地渴望将事情做好，他们就极有可能将外部咨询视为增加其工作负担的麻烦。当然，也存在另一种可能：对方对事情本身有兴趣，只是不认为你有能力解决它，结果就是对方缺乏与你深入交流的动力。

如果遭遇这种情况，我们的交付策略就需要向第二点进行延伸和调整。

二、转向人员能力培养

如果从企业方获得的实质性帮助和支持非常有限，并且你从客观判断本次咨询很难输出关键性的技术方案或解决路径，那么明智的做法是迅速转向第二条路径：“放弃紧盯‘事’，开始聚焦‘人’！”

例如，如果是为产研团队提供咨询，那么可以拉着这支团队持续进行培训和赋能，可行的动作包括：

1. 进行系统的AI认知与前沿趋势输入。
2. 分享行业内外的成功与失败实践案例。
3. 共同攻坚一个具体项目（务必选择中等规模的项目，目标是传授方法论而非包办）。
4. 针对关键技能（如提示工程、评估方法、大模型API集成等）进行专题探讨。
5. ……

这背后的逻辑在于：“事情本身如果难以推进，那么帮助甲方公司的关键人员实现能力素质的显著提升，也是一种有价值的交付！” 正所谓东方不亮西方亮，企业支付了费用，总需要获得某种形式的回报。

在此基础之上，还可以进行更多延伸，例如帮助他们定义AI时代的人才画像、指导他们如何面试和选拔合适的人才、甚至可以协助面试，或者在必要时推荐合适的候选人。

总而言之，只要能够切实提升目标团队的整体能力，这也算是一次成功的咨询交付！那么问题又来了：如果“事”不行（缺乏足够材料，难以产出有效方案），同时“人”也不行（员工能力不足或学习意愿薄弱，未能学到东西），那又该怎么办呢？

三、提供情绪价值

如果一次咨询已经很难产生良性的、实质性的成果物，也未能让目标团队成员的能力得到提升，那么此时基本上可以进入 “止损” 路径了。

近期观察到许多学习者在运用提示词与大模型交互时，输出结果仍有较大提升空间。因此，本文对核心教学课件进行梳理与提炼，旨在系统性地介绍提示词的基础知识与实用技巧。

大语言模型的本质是一个预测引擎。它根据我们输入的上下文，计算出下一个最可能的词语（Token）。这个过程类似于高难度的“成语接龙”，模型基于海量文本训练出的规律，持续预测后续内容。

提示词是我们给予大模型的输入指令。其核心作用是引导模型，使其预测出的下一个乃至一连串的Token都能符合我们的预期目标。提示词工程则是一套通过持续优化输入内容，以系统性提升模型输出质量的方法论。它主要围绕三个关键维度展开：

1. 质量维度：确保输出的内容具备专业性、完整性和高价值，让使用者感觉“切中要害”。
2. 稳定性维度：保证模型在不同情境和时间下，都能产生稳定、可预期的表现，让人感觉“可靠信赖”。
3. 正确性维度：保障输出信息的准确度与可信度，避免生成虚假或具有误导性的内容，让人感觉“言之有据”。

当然，提示词工程并非无所不能。它无法突破基础模型本身的能力上限，也不能保证输出的绝对正确。它的核心价值在于，能够在模型现有的能力范围内，显著提高其输出符合期望结果的概率。

二、提示词的分类：系统提示词与用户提示词

根据使用场景和设定者的不同，提示词主要分为系统提示词和用户提示词，二者区别显著：

• 系统提示词：在开发AI应用时，开发者预先为模型设定的角色定位、行为准则和回复逻辑。它作为模型的初始化参数，在整个对话会话中持续生效，深远地影响着模型的响应模式和风格。
• 用户提示词：用户在与AI应用进行具体对话时输入的指令或问题。它是用户向模型发起的即时任务请求，旨在指导模型完成某个特定动作或提供特定信息。

举例说明：假设我们需要构建一个健康咨询助手。

• 系统提示词示例：“你是一个友好且专业的健康咨询助手，专注于为用户提供基于循证医学的科学健康建议。你的回答应当谨慎，避免给出明确的诊断，并建议用户对于严重症状及时就医…”
• 用户提示词示例：“我最近一周总是感到异常疲劳和嗜睡，可能是什么原因？需要注意什么？”

三、提示词的常见格式与选择

撰写提示词可采用多种格式，如自然语言、Markdown、XML、伪代码等。格式本身并无绝对优劣，关键在于能否通过结构化的表达，让模型清晰理解指令，并明确区分指令与待处理内容之间的边界。

以下简要介绍几种主流格式及其适用场景：

1. 自然语言

你是一个代码评审专家，请帮我检查下面的代码是否存在问题，并给出优化建议。  
注意：不要重写完整代码，只指出问题和改进点。

特点：最为直观、简单，适合普通用户处理简单任务。然而，在复杂场景下容易产生歧义，对指令的约束力较弱。

2. Markdown

# 角色  
代码评审专家  
# 任务  
检查我提供的代码，指出潜在问题并给出优化建议  
# 要求  
- 不要重写完整代码  
- 按问题点逐条说明  
- 说明原因及改进思路

特点：兼顾简洁与强大的结构化能力，是大模型提示词工程中最常用的格式之一。其清晰的标题、列表层级能有效帮助模型划分内容区块，理解任务结构。

3. XML

<角色>  
  代码评审专家  
</角色>  
<任务>  
  检查我提供的代码，指出潜在问题并给出优化建议  
</任务>  
<要求>  
  <规则>不要重写完整代码</规则>  
  <规则>按问题点逐条说明</规则>  
  <规则>说明原因及改进思路</规则>  
</要求>

特点：结构极其清晰，标签化的方式使得层次分明，便于模型精准解析。虽然对普通用户而言稍显繁琐，但非常适合处理包含多部分输入、复杂约束条件的任务。

4. 伪代码

## 规则判断执行（顺序如下）：  
----------  
IF 天数 < 3:  
RETURN false + "数据量不足，建议延长实验"  
IF 最长连续负向天数 ≥ 3 AND 最后一天 ≤ 0% AND 最后2天无正向:  
RETURN true + "连续X天用户减少，最后仍未好转，建议停止实验"  
... (其他条件分支)

特点：使用编程式的控制逻辑（如 IF/ELSE）来编写提示词，最大程度地减少了自然语言的歧义。适用于复杂决策、多条件判断、智能体（Agent）提示或工作流场景，能明确告知模型在不同条件下的行动路径。