AI智能体项目最佳实践——第三章：通过技能、工具和 MCP 注入私有能力

如果说知识让智能体变得有信息量，那么能力让智能体变得有影响力。这个区别很重要，因为一旦智能体能够改变系统状态——开票、重置密码、发起采购、推工作流——工程问题就不再只是答案质量，而是副作用、权限、可逆性和责任归属。能力注入因此不是知识注入的简单孪生兄弟，而是一个完全不同的工程问题。平台必须描述智能体可以用什么身份、带哪些参数、通过什么集成边界、在什么审查条件下执行什么动作。一个带有模糊语义的副作用操作是危险的。

一个企业级的能力远不止一个函数签名那么简单。它必须包含业务目的、输入模式、副作用说明、身份假设、失败模式和审计需求。仅仅把函数命名为“创建服务工单”是不够的，还要回答：谁允许开单？工单必须绑定到认证用户还是可以代他人开？优先级是自由文本还是枚举？重复调用会不会产生重复工单？调用后必须记录什么？这些问题说明能力设计应该与系统设计并列，而不是被当作提示工程的花边。在传统应用中，人类编写命令式代码调用函数时有明确的目的，而在智能体系统中，模型需要自行决定是否应该调用该函数，这使得契约变得更加重要——它不再是给开发者看的便利文档，而是智能体的行为边界。

读能力和写能力应当被明确区分。读操作虽然也需要访问控制，但很少需要回滚；写操作则会创建持久状态、触发工作流、通知人类或消耗资金，因此需要更高的验证标准，通常还需要审批。成熟的智能体系统应该在工具注册层面就让这种差异可见，平台应当知道一个能力是只读的、改变状态的、不可逆的还是需要审批的。如果这些属性被藏在运行时无法使用的文档里，系统就无法一致地保护自己。MCP作为一种标准化协议，让企业可以用统一的方法暴露外部能力，减少重复的胶水代码，但标准化只有在配合治理时才有用，否则它只会让不理解的行动更容易被大规模导入。

在实验层面，可以构建一个资产支持助手，实现两个能力：一个是读能力“查询资产所有者”，另一个是写能力“创建服务工单”。首先用自然语言描述每个能力的业务目的、输入、副作用级别和审批假设，然后再转化成形式化的模式。将这两个能力注册到共享的能力层之后，验证从不同的客户端（Web聊天、Lobster、Hermes工作流）都能以一致的语义调用它们。然后通过不同的提示词测试系统能否正确区分读和写：询问资产所有者应该只触发读操作，而要求为故障笔记本开一个高优先级工单则应该触发写操作并进入审批流程。如果智能体区分不了这两者，说明能力边界定义得不够清晰。观察结果的塑造也很重要，查询资产所有者应该返回所有者姓名、部门和资产状态，创建工单后应该返回工单号、队列、优先级、创建时间和审批状态，这些简洁的信息比原始API转储更适合模型进行后续推理。最后，通过MCP接入一个外部能力，比如日历查询，并检查信任边界，明确哪些外部能力值得与原生能力同等的信任。能力治理还包括版本管理和组合管理，一个能力可以被标记为已废弃但仍然保留在过渡期内，平台团队应该跟踪每个能力的调用强度、失败率和所有者，把能力注册表从一堆集成变成受管理的产品组合。

电子版链接：[https://book.yunzhan365.com/ultjm/kuki/mobile/index.html]

通过网盘分享的文件：Best-Practice-for-AI-Agents-Project_Part-03_Injecting-Private-Capabilities-with-Skills-Tools-and-MCP.pdf
链接: [https://pan.baidu.com/s/1A5-Vn1ttCOq8X0VwXIx8sQ]提取码: yw25