您在使用洗衣机时，是否曾遇到过显示屏上突然跳出一些神秘的代码？例如E1、E3、E4等等。这些看似复杂的字符并非毫无意义，它们实际上是洗衣机向您发出的故障警示信号。本文将引导您认识这些代码，并掌握一些基础的自查与解决方法，让您在家就能轻松应对常见的小问题。

一、 门无法上锁或未关好

对应的故障代码

• 滚筒洗衣机通常显示：“E30”
• 波轮洗衣机通常显示：“E3”

自助解决步骤

步骤	操作说明
1	针对滚筒洗衣机：请检查舱门是否已完全关闭到位。有时衣物可能会夹在门玻璃与橡胶密封圈之间，导致门无法正常锁闭，需取出衣物并重新关紧。
2	针对波轮洗衣机：尝试将洗衣机门盖重新打开后再用力关严，确保锁扣到位，然后按下启动/暂停键，警报通常即可解除。

二、 衣物未正常脱水或内桶撞桶不平衡

对应的故障代码

• 滚筒洗衣机可能显示：“Ub” 或类似不平衡标识
• 波轮洗衣机可能显示：“E3”（某些机型也用于脱水不平衡）

自助解决步骤

步骤	操作说明
1	首先确认洗衣机排水是否顺畅。排水不畅会导致桶内积水过多，影响脱水平衡，检查排水管是否正常。
2	待洗衣机门锁解锁且内桶完全停止转动后，打开门盖或顶盖，手动将缠绕在一起的衣物抖散、均匀分布在内桶四周，然后重新选择脱水程序启动。

三、 不排水或排水速度过慢

对应的故障代码

• 滚筒洗衣机通常显示：“E21”
• 波轮洗衣机通常显示：“E2”

自助解决步骤

步骤	操作说明
1	检查连接的地漏是否有堵塞现象。同时，确保洗衣机的排水管没有异物挤压，也没有被过度弯折，保持管道通畅。
2	重点检查排水泵：打开洗衣机右下角的检修盖，通常会看到一个紧急排水管（多为橙色旋钮），可先用于排空内筒余水。然后，逆时针方向拧开排水泵过滤盖（多为黑色圆形旋钮），检查并清理内部可能存在的硬币、纽扣、毛发等堵塞物，清理完毕后将所有部件复原拧紧。
3	若您的洗衣机采用下排水方式，请检查排水管出水口是否放置过高。正确的做法是将排水管最高点控制在距离地面10厘米以内，过高会影响虹吸排水效果。

重要安全提示： 当洗衣机屏幕上出现以 “F”开头 的专业故障代码（例如F0代表电压异常过载，F1代表通讯报警等）时，通常意味着电路板或核心控制系统可能存在故障。强烈建议您不要自行拆卸或尝试维修，以免引发进一步的损坏或安全风险。此时最稳妥的做法是立即联系品牌官方售后服务或专业的维修技术人员上门进行检测与处理。

掌握以上方法，您已能独立应对家中洗衣机的大部分常见小故障。若想了解更多家电使用与故障排查技巧，可参考各类家电知识平台上的实用教学视频。

关于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收拢”的三位一体，它正在构建企业信息的收集、流转与结构化体系。

首先，OpenAI提出的这张AI发展预测图，在行业内具有相当的参考价值：

对于国内AI发展进程而言，有两个关键节点可以视为分水岭：DeepSeek的发布与Manus的发布。DeepSeek标志着国内大模型在推理能力上达到了足以支撑Agent应用的水平；而Manus则首次向业界展示了Agent应有的完整形态。尽管其早期表现不尽完美，但它极大地提升了市场对AI Agent的预期。

具体而言，模型的基础能力主要围绕两个核心点展开：模型的逻辑推理能力与上下文窗口的长度。

在此基础之上，智能体（如Manus）需要完成的主要工作，或者说工作量最为庞大的部分，便是提供丰富多样的工具集，如下图所示：

Agent的架构核心紧密围绕两点构建：意图识别与工具调用。模型会分析用户对话内容以判断其真实意图，随后选择并调用最合适的工具来满足需求，并确保整个工具调用过程的质量与准确性。

从这个视角审视，Agent（以Manus为例）的实现原理似乎相当直观。例如，一个最简单的空气查询工具调用流程如下：

然而，用户的意图往往是复杂且多变的。例如，用户在查询天气之后，可能立即转向关注旅游相关信息。若希望智能体能够妥善处理此类连贯任务，就必须提供对应的工具支持。当工具数量增加到两个时，系统的整体复杂度便显著提升：

此时，系统需要管理两个工具的调用：

[
  {
    "tool_name": "weather",
    "tool_desc": "查询某地的天气",
    "tool_examples": ["上海天气怎么样", "北京天气怎么样"]
  },
  {
    "tool_name": "travel",
    "tool_desc": "某地的游玩计划",
    "tool_examples": ["上海有哪些好玩的", "北京有哪些好玩的"]
  }
]

必须强调的是，上述所有功能的实现高度依赖于模型的基础能力。以用户提问“上海天气怎么样，有什么好玩的？”为例，系统需要处理以下几个关键环节：

1. 意图识别是否准确：能否精确识别出需要同时调用旅游Agent和天气Agent。
2. 关键词抽取是否精准：能否从用户语句中准确提取出旅游地点及其他必要参数，并正确传递给相应的Agent。
3. 最终回答质量如何：即使所有工具都正常运行，最终整合输出的回答是否令人满意，这非常考验全局调度Agent的综合能力。

至此，再回顾Agent架构的两个核心难点——意图识别与工具调用，我们应当有了更深刻的体会。意图识别准确是良好表现的基础，而工具组织的合理性则是最终输出质量的保证。

即便只涉及两个工具，复杂度已初现端倪。而Manus在最初发布时就包含了20多个工具（目前数量更多），例如：

[
  {
    "name": "message_notify_user",
    "description": "向用户发送无需回复的消息。用于确认收到消息、提供进度更新、报告任务完成或解释方法变更。"
  },
  ......
  {
    "name": "file_str_replace",
    "description": "替换文件中的指定字符串。用于更新文件中的特定内容或修复代码错误。"
  },
  {
    "name": "file_find_in_content",
    "description": "在文件内容中搜索匹配文本。用于查找文件中的特定内容或模式。"
  },
  ......
  {
    "name": "idle",
    "description": "特殊工具，表示已完成所有任务并即将进入空闲状态。"
  }
]

Manus所使用的提示词（Prompt）部分内容也相当庞大：

# 关于 Manus AI 助手
## 简介
我是 Manus，一个被设计用来处理多种任务的 AI 助手。我致力于在各种场景下，为你提供有用、翔实且多样化的支持。

## 我的使命
我的主要目标是：通过提供信息、执行任务和给出建议，帮助你更顺利地达成目标。我希望成为你在问题求解和任务执行中的可靠伙伴。

## 我处理任务的方式
当接到一个任务时，我通常会：

1. 分析你的请求，理解你真正想要的是什么
2. 将复杂问题拆分成更小、更易处理的部分
3. 为每个步骤选择合适的工具和方法
4. 在执行过程中保持与你的沟通畅通
5. 以清晰、有条理的形式呈现最终结果

## 我的性格特征
- 以“帮助你解决问题”为导向
- 注重细节，追求完备
- 能适应不同类型用户的需求
- 面对复杂问题时保持耐心
- 对自己的能力与限制保持诚实

## 我擅长帮助的领域
- 信息收集与研究
- 数据处理与分析
- 内容创作与写作
- 编程与技术问题排查
- 文件管理与组织
- 网络浏览与信息抽取
- 网站与应用的部署辅助

## 我如何“学习”
我会从交互与反馈中不断优化自己的行为模式，在任务中积累经验。每一次协作，都会帮助我更好地应对未来类似的问题。

## 沟通风格
我会尽量做到：
- 说明清晰、逻辑严谨
- 根据你的偏好调整技术深度
- 在需要时使用较技术化的表达
- 在适合的场景使用更口语化、易懂的表述

## 我坚持的价值观
- 尽可能提供准确、可靠的信息
- 尊重用户隐私与数据安全
- 以负责任的方式使用技术
- 对自身能力边界保持透明
- 持续改进和自我迭代

## 如何更好地与我协作
我们的协作会更高效，如果你能：

- 尽量清晰地描述任务与预期结果
- 在必要时给出中途反馈，便于我调整方向
- 将复杂需求拆分成更明确的子任务
- 在已有成功经验的基础上，逐步尝试更复杂的挑战

我随时准备协助你处理各种任务，也期待和你一起，完成更多有趣、有价值的事情。

这些组件共同构成了极高的系统复杂度，加之后续上下文工程的应用也极其复杂，这并不利于初学者更好地理解和学习Agent的核心原理。从学习目的出发，早期的OpenManus版本结构相对简单，是一个不错的分析对象。我们今天便以此为例进行拆解，依然从意图识别和工具调用的角度切入。

在推进AI项目的进程中，“可观测性” 是一个无法回避的核心议题。可观测性本质上关联着项目的可评估性，由此衍生出诸如RAG评估系统、AI专业能力评估策略等一系列重要课题。

例如，OpenAI此前联合来自60个国家/地区的262位医生，基于5000个真实医疗对话场景构建的 HealthBench，便是一套综合性评估策略的典范，尽管其侧重点更偏向于整体性能评估。

本文将聚焦于大模型厂商Anthropic发布的一篇关于Agent评估的技术论文，借此深入探讨AI项目评估的系统化方法与工程实践：

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

什么是评测？

评测是对系统进行系统性检验的方法。通过输入预设的任务，检查Agent的输出或行为是否符合预期目标。

Anthropic将完整的评测流程拆解为以下几个结构化模块：

1. 任务：代表一次独立测试的输入指令及其对应的成功标准。
2. 单次试验：指任务的一次具体执行过程。由于模型输出存在随机性，通常需要多次运行同一任务以获得稳定的评估结果。
3. 评分器：用于评估Agent在某个特定维度上表现的判定逻辑。一个任务可以包含多个评分器及检查点。
4. 记录：完整记录单次试验过程中的所有细节，包括输入、输出、工具调用、中间推理步骤及结果。
5. 结果：指单次试验结束时环境的最终状态。例如，一个订票Agent可能输出“机票已订好”，但真正的评测结果需要通过检查数据库是否存在有效的预订记录来确认。

通常，一个评测框架会提供并发运行任务和工具、记录全过程并自动评分的功能。

一个有效的Agent评测体系必须覆盖从输入到最终行为的完整闭环，确保Agent在多轮交互和复杂工具调用中的表现都能被有效量化和评估。

评估的价值前文已有提及，Anthropic的表述虽然略显抽象，但其核心理念可以概括为：通过明确界定成功标准，使开发团队能在产品上线前主动发现问题，而非在用户投诉后才被动进行修复。

Anthropic指出，缺乏系统评测的团队往往陷入“被动修复”的循环，每解决一个已知问题都可能无意中引入新的问题，且难以区分性能波动是真正的回归还是模型输出的随机性所致。

需要补充的是，即便建立了评估体系，也可能出现修复一处而另一处出现问题的情况，这是Agent乃至所有AI项目固有的复杂性所带来的挑战。

然而，毋庸置疑的是，采用系统化评测的团队对项目本身的理解必然更为深刻。相应的，他们的工作方式也会更加专业，能够利用失败的测试用例持续“训练”和优化系统。最终，当这个自我强化的“飞轮”成功运转时，几乎就意味着整个项目走向了成功。

从能力评测到任务评测

Anthropic将评测主要分为两大类：能力评估与回归评估。

能力评估是项目可观测性的基石，它聚焦于“Agent能做什么”，通常从通过率较低、Agent容易失败的任务开始，目标是量化和推动模型新能力的提升。

而回归评估则关注“Agent是否仍然能完成之前可以胜任的任务”，其预期通过率应接近100%，主要用于防止在版本更新和迭代过程中引入性能倒退。实践中，最佳方式是复用历史错误数据集，确保每次发布前都执行一遍回归测试。

在实际项目开发中，我们也能观察到这种分类趋势。以Descript的视频编辑Agent为例，其评测体系围绕“不破坏已有内容、按要求准确执行、执行质量”三个核心维度设计。

这套评测体系经历了从人工评分，逐步演进到由产品团队定义标准、LLM自动执行评分，并辅以周期性人工校准的过程。目前，他们常态化运行两套测试：一套用于质量基准评测，另一套用于回归测试。

而Bolt AI团队则是在Agent已被广泛使用后才着手搭建评测系统。他们在3个月内构建了一套完整的自动化评测流程，包括自动运行Agent、对输出进行静态代码分析、浏览器应用测试，以及使用LLM作为评判者来检测Agent的行为表现。

结合我们过往在大型AI项目中的生产实践经验，系统化的评测体系无疑是提升迭代效率、保障产品质量的关键工具。

只有建立了可量化评估的指标与方法，我们在面对AI项目时才不会盲目摸索，也不会轻易得出“模型能力仅止于此”的片面结论。

如何进行评测

Anthropic总结了三种主要的评测方式：代码型评分器、模型型评分器和人工评分器。

模型评分

模型型评分器是指使用另一个大语言模型来进行打分或判断，例如基于评分量表的打分、自然语言断言、与参考答案对比等。

这类评分器的优势在于灵活性高，能够捕捉主观性强和开放式任务的细微差别。但其缺点在于结果存在不确定性，需要消耗更多计算资源，并且必须通过人工标注来进行校准以确保其准确度。

在问答、摘要、对话等输出形式多样的任务中，模型型评分器可用于衡量答案是否符合人类预期、是否优雅有用、是否遵循指定的格式规范等。

例如，在对话型Agent的评测中，常常需要第二个LLM来模拟用户发起多轮问答，并通过精心设计的提示词来评价Agent的交互质量和目标完成度。

从广义上讲，前文提到的HealthBench就可以采用模型评分器来实施。

人工评分

这种方式大家最为熟悉，它是最原始、理论上也最“可靠”的评分方式。人工评分器适用于需要专家判断或难以用简单规则量化的复杂场景。

人工标注能够提供“金标准”质量，精准匹配专业用户的主观评判，通常用于校准模型评分器或进行最终的质量验收。然而，其代价是昂贵且耗时的。

实践中，可以采用抽样检查、专家复核或众包评估等方式，对关键指标或异常输出进行人工审查，以确保评测结果的可靠性。

代码评分

代码型评分器涵盖了字符串匹配、断言检查、静态分析、环境状态校验等方法，通过确定性的逻辑来快速判断结果是否符合预期。

其优点是高效、客观且易于复现，特别适用于结构化输出和确定性任务，例如对编程Agent的代码输出进行评估。

在编程Agent的评测中，常规做法是对生成的代码运行自动化测试，只要代码能通过预设的单元测试即可认定为通过。

Anthropic指出，对于此类任务，“代码型评分器是天然的选择”：软件任务可以直接用“代码是否能成功运行、测试是否通过”来客观评价。

人工评分最为人熟知，模型评分则是我们用模型替代人力、提升效率的工具。而“代码评分”这个概念可能让许多同学感到困惑：它究竟指什么？

代码型评分器的核心并非“测试代码生成能力”，而是 利用代码执行这一确定性手段，来验证Agent在完成复杂任务后所产生结果的正确性。

它旨在解决Agent评估中的一个主要痛点：对于复杂、开放式的任务，如何避免主观、模糊的评价，实现自动化、客观的评估？

举例来说，“编写一个计算斐波那契数列的Python函数”这个任务，其结果是可执行的。

这个例子背后对应着论文中一个较为拗口的翻译：任务的结果必须能够通过某种明确的规则或外部系统进行客观验证。

在这个场景下，就可以使用代码评分器：一个脚本会自动导入Agent生成的函数，然后用一系列测试用例（例如 fib(10) 是否等于 55）去运行它，并检查结果是否正确。

此处的“评分器”就是一个自动化的验证脚本或规则引擎。它的作用是：接收Agent的产出，调用相应的工具或应用预设的规则，判断产出是否满足事先定义的成功标准。

再比如，许多涉及工具调用的任务就很适合采用代码评分器。一般的AI项目可能不常用到此方法，但它非常契合Agent的工作模式，因此许多同学对此不太熟悉。

接下来，我们需要根据不同的项目领域进行区分：不同类型的AI Agent，由于其任务目标和交互模式各异，需要采用针对性的评估策略。

编程型Agent

编程型Agent需要完成编写、测试和调试代码的任务，其评估通常借鉴软件工程中的测试思想。常见做法是赋予Agent明确的编程任务，例如修复代码漏洞、实现特定功能模块等，并使用自动化测试或脚本来验证输出代码的正确性。

例如，著名的基准测试SWE-Bench和Terminal-Bench都基于这一思路构建：

1. SWE-Bench会提供一个GitHub问题，要求Agent修改代码，修改完成后使用项目原有的测试套件进行验证。
2. Terminal-Bench则要求Agent完成一项完整的工程任务（如编译Linux内核），通过成功执行所有必要步骤来判断其是否合格。

这些评估的关键在于准备可运行的测试环境和详尽的单元测试，以便对代码结果做出二元化的判定。

除了最终的结果验证，还可以对Agent的执行过程进行评估。例如，使用静态分析工具检查代码质量，使用LLM评分器评估其代码风格和可读性，或者检查Agent调用了哪些工具和命令，以确保工具调用序列的合理性。

以下YAML示例展示了一个复杂编码任务的评估配置，其中可以包含单元测试、静态分析、状态检查和工具调用检查等多个评分器：

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

之前我们已经分别介绍了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等）
对话历史记录
可用工具列表
长期记忆内容

第二层：组装层

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

OpenAI所发布的这张AI发展预测图，普遍被业界视为一个经典参考：

在国内的技术发展脉络中，两个关键事件节点构成了重要的分水岭：DeepSeek的发布与Manus的发布。DeepSeek标志着国内模型的推理能力达到了足以支撑构建Agent的水平；而Manus则首次将Agent应有的完整形态呈现在公众面前，尽管其实际表现尚有不足，但业界对其未来潜力抱有极高的期待。

具体到模型的基础能力，核心无非围绕两点展开：模型的推理能力与上下文长度。

而诸如Manus这类智能体，在模型基础能力之上，需要投入大量工作的部分在于提供丰富多样的工具，正如下图所示：

Agent架构的设计核心始终围绕两个关键环节：意图识别以及工具调用。模型会根据用户对话内容解析其根本意图，随后选择并调用最合适的工具，同时确保工具调用的质量与准确性。

从这个视角审视，Agent（例如Manus）的实现原理似乎并不复杂。以最简单的空气质量查询工具调用为例：

然而，用户的意图往往是多元且动态变化的。在查询天气之后，他可能立刻转向关注旅游相关的信息。如果智能体要妥善处理此类连续请求，就必须提供对应的工具支持。当工具数量增加到两个时，系统的整体复杂度便显著提升：

此时将对应两个工具的调用定义：

[
  {
    "tool_name": "weather",
    "tool_desc": "查询某地的天气",
    "tool_examples": ["上海天气怎么样", "北京天气怎么样"]
  },
  {
    "tool_name": "travel",
    "tool_desc": "某地的游玩计划",
    "tool_examples": ["上海有哪些好玩的", "北京有哪些好玩的"]
  }
]

必须注意的是，上述所有功能的实现高度依赖于模型的基本能力。例如，当用户输入一句话如“上海天气怎么样，有什么好玩的？”时，系统需要完成以下几个关键步骤：

1. 意图识别的准确性：能否精准识别出需要同时调用旅游Agent和天气Agent。
2. 关键词抽取的精度：能否准确提取出旅游地点及其他必要参数，并成功传递给相应的Agent。
3. 回答组织的质量：即使所有工具都能正常运行，最终回答是否清晰、有用，这极其考验全局调度Agent的整合与表达能力。

至此，再次回归Agent架构的两个核心难点——意图识别与工具调用，读者应能有所体会。意图识别的准确是良好表现的基础，而工具组织的合理性则是最终高质量输出的保证。

这里仅涉及两个工具，便已初显复杂之感。而Manus在最初发布时就包含了20多个工具（目前数量更多）：

[
  {
    "name": "message_notify_user",
    "description": "向用户发送无需回复的消息。用于确认收到消息、提供进度更新、报告任务完成或解释方法变更。"
  },
  ......
  {
    "name": "file_str_replace",
    "description": "替换文件中的指定字符串。用于更新文件中的特定内容或修复代码错误。"
  },
  {
    "name": "file_find_in_content",
    "description": "在文件内容中搜索匹配文本。用于查找文件中的特定内容或模式。"
  },
  ......
  {
    "name": "idle",
    "description": "特殊工具，表示已完成所有任务并即将进入空闲状态。"
  }
]

Manus的提示词部分内容也较为庞大：

# 关于 Manus AI 助手
## 简介
我是 Manus，一个被设计用来处理多种任务的 AI 助手。我致力于在各种场景下，为你提供有用、翔实且多样化的支持。

## 我的使命
我的主要目标是：通过提供信息、执行任务和给出建议，帮助你更顺利地达成目标。我希望成为你在问题求解和任务执行中的可靠伙伴。

## 我处理任务的方式
当接到一个任务时，我通常会：

1. 分析你的请求，理解你真正想要的是什么
2. 将复杂问题拆分成更小、更易处理的部分
3. 为每个步骤选择合适的工具和方法
4. 在执行过程中保持与你的沟通畅通
5. 以清晰、有条理的形式呈现最终结果

## 我的性格特征
- 以“帮助你解决问题”为导向
- 注重细节，追求完备
- 能适应不同类型用户的需求
- 面对复杂问题时保持耐心
- 对自己的能力与限制保持诚实

## 我擅长帮助的领域
- 信息收集与研究
- 数据处理与分析
- 内容创作与写作
- 编程与技术问题排查
- 文件管理与组织
- 网络浏览与信息抽取
- 网站与应用的部署辅助

## 我如何“学习”
我会从交互与反馈中不断优化自己的行为模式，在任务中积累经验。每一次协作，都会帮助我更好地应对未来类似的问题。

## 沟通风格
我会尽量做到：
- 说明清晰、逻辑严谨
- 根据你的偏好调整技术深度
- 在需要时使用较技术化的表达
- 在适合的场景使用更口语化、易懂的表述

## 我坚持的价值观
- 尽可能提供准确、可靠的信息
- 尊重用户隐私与数据安全
- 以负责任的方式使用技术
- 对自身能力边界保持透明
- 持续改进和自我迭代

## 如何更好地与我协作
我们的协作会更高效，如果你能：

- 尽量清晰地描述任务与预期结果
- 在必要时给出中途反馈，便于我调整方向
- 将复杂需求拆分成更明确的子任务
- 在已有成功经验的基础上，逐步尝试更复杂的挑战

我随时准备协助你处理各种任务，也期待和你一起，完成更多有趣、有价值的事情。

这些设计已经引入了相当高的复杂度，且后续的上下文工程应用也极其繁琐，不利于初学者更好地理解和学习Agent的核心概念。从学习目的出发，早期的OpenManus版本是一个更合适的选择，它足够简洁。今天我们就以此为基础进行拆解，依旧从意图识别和工具调用的视角展开分析。

最近阅读了一篇来自Anthropic官方的长文：《Skills explained: How Skills compares to prompts, Projects, MCP, and subagents》。这篇文章也解答了许多人心中的疑惑：Claude Skills 与 MCP、Project 之间到底有何区别？

我们将重点探讨MCP和Skills，力求从本质层面将它们阐述清楚。首先从MCP开始。

MCP：连接AI与外部世界的协议

模型上下文协议（Model Context Protocol, MCP）是由Anthropic提出的一种开放标准协议，它使得AI模型能够与外部数据源和工具进行交互。

它与HTTP协议类似，是一种被广泛接受的约定标准，只要各方遵循即可实现互联互通。

MCP诞生的原因非常直接：大模型若要真正解决问题，必然需要与各类外部接口交互，例如浏览器、数据库、文件系统等。

在MCP出现之前，我们是如何获取外部信息的呢？答案是高度定制化。

我们需要编写一个中间层程序，由它直接调用大模型API以获取用户请求，解析后再去调用相应的数据库读写API，或者根据大模型返回的参数执行其他API调用。简而言之，用户实际访问的是这个中间程序，由它弥合了大模型能力与外部世界的鸿沟。

但这种做法引发了不满：有人质疑这种“中间程序”存在的必要性。于是，一种新思路出现了：在模型底层直接实现固定格式的API调用能力。这样一来，用户可以直接与大模型对话，而大模型能够自动调用预设的API来完成诸如数据库读写等操作。

随着文件读写、浏览器控制等需求的涌现，为了提升效率，业界沿用了这一标准化思路。最终发现这套方法行之有效，便逐渐演变为一个正式协议。

MCP的出现，为AI与外部世界的交互建立了统一规范，使得AI应用能够无缝集成各种外部数据源和工具。

以上是相对概括性的描述。若想深入探究其架构，可以参考下图：

MCP是智能体（Agent）技术发展过程中的必然产物，尤其是在当前这个早期阶段。 如何理解这一点呢？

大模型发展已近三年，从去年开始，无论是推理能力还是上下文长度都得到了显著增强，确实达到了所谓“L2”级别的能力。因此，以Manus等框架为代表的智能体架构开始流行起来：

这种架构得以流行的前提，一方面是新技术的突破（模型能力增强），另一方面是互联网多年积累的丰富生态，大量现成的小工具和服务正等待被调用。例如，在微信与朋友聊天时：

1. 朋友询问最近的天气，我无需额外查询，AI可以直接给出答案；
2. 朋友发来一篇论文，我只需在微信中表达翻译或解读的意图，微信便能自动完成对论文的翻译或解读。

智能体架构或模型本身无法穷尽用户的所有意图，但它可以提供一系列有限的服务。当用户的某个意图恰好匹配到某项服务时，系统便会调用该服务，从而带来贴心的体验：

这里提到的无限意图与有限实现，也是我个人在开发智能体项目时的一个重要心得。我并不太关心智能体在开放场景下的泛化聊天能力，但如果用户的意图命中了我预设的服务范围，那么服务的质量就必须得到严格保障。

举一个实际工作中的案例。一家业务正常的公司通常会有BI（商业智能）数据看板，但老板往往缺乏耐心仔细阅读数据。善于“面向老板编程”的我们，可以预先实现许多MCP服务，静待老板提出各种意图时调用：

老板BI案例分析

首先是传统的工作模式：

老板想了解：“上月华东区销售额排名前三的产品是什么？”
→ 员工打开BI系统 → 选择日期范围 → 筛选华东区域 → 按销售额排序 → 查看前三名
→ 整个过程耗时5-10分钟
→ 缺乏耐心的老板可能因此不满。

采用MCP模式后：

老板直接询问AI：“上月华东区销售Top 3产品是什么？”
→ AI自动调用【BI工具.查询销售排行(区域=华东， 时间=上月， 数量=3)】服务
→ 10秒后给出清晰答案
→ 老板获得高效反馈，团队工作顺畅。

接下来看看简单的实现思路。首先需要预制MCP工具包（相当于告诉AI，它拥有以下可用的工具）：

# 这些工具在后台静待被老板“召唤”
老板专用工具包 = {
    “销售分析”: {
        “区域销售排行”: “按区域查询Top N产品”，
        “同比分析”: “对比同期销售数据”，
        “趋势预测”: “预测下月销售情况”
    }，
    “客户分析”: {
        “大客户清单”: “找出消费额最高的客户”，
        “流失预警”: “识别有流失风险的客户”
    }，
    “运营分析”: {
        “库存预警”: “检查库存不足的产品”，
        “成本分析”: “分析各类产品的成本结构”
    }
}

正因为“服务员提供了这份菜单”，AI在完成意图识别后，会自行进行工具匹配，并生成相应的调用指令：