企业应向 AI 智能体开放哪些功能？

当某项具体的客户任务适合由 AI 助手完成，而且你的系统能够执行必要限制时，再开放可调用功能。先明确任务、所需数据和结果负责人。公开常见问题可能只需要一个更清楚的页面。客户的非公开订单状态需要访问控制。预约则需要明确的批准与确认流程。

“可被智能体调用”是指助手能够使用你开放的某个功能，例如查询是否有空位。它不意味着让助手全面访问你的系统。

选定第一项任务及其边界

假设一家服务公司的客户经常询问工作是否完成。第一项实用工具可以是返回单个项目的状态。它的规则应明确：

• 调用方必须有权查看该项目，知道项目编号并不够。
• 回答只包含允许向客户展示的状态、最后更新时间和支持渠道，不包含内部备注或其他客户的记录。
• 工具不能修改项目、发放退款，也不能承诺源系统中不存在的完成日期。
• 如果来源不可用或访问失败，应说明实际状态，不能编造进度。

开发新界面前，先与现有客户门户比较。如果门户已经能解决问题，就要明确客户为什么需要助手连接，以及谁负责维护。

首个版本应将支付、退款、破坏性修改和个人数据批量导出排除在可调用范围之外。每项扩展都应单独批准和测试。要求模型遵守规则的提示词，不是访问控制。

只读访问同样需要保护

读取也可能泄露私人文档、展示其他客户的订单，或把旧价格当作现价。这些情况即使不修改数据库记录，也可能伤害客户。

应根据已验证身份和服务器端权限确定访问范围。助手传入的 account_id 不能证明用户有权使用该账户。即使属于同一组织，也并非每名员工都有权查看所有文档。

MCP 提供什么，还需要实施什么

Model Context Protocol（MCP）是向助手开放工具的一种方式。以下资料采用 2026 年 7 月 28 日修订版，于 2026 年 10 月 9 日核查。请确认实际客户端和服务器支持哪些版本。

授权规范涵盖 HTTP 授权，包括令牌校验和权限范围，不只是传递登录信息。你的实现仍需把已授予权限对应到允许的操作与记录。发给其他服务的令牌，即使有效，也不能被接受。

工具规范要求服务器验证输入、执行访问控制、限制调用频率并净化输出。它建议保留人工监督和确认提示，但并未规定唯一的交互设计。连接上 MCP 客户端，不能证明这些控制已在你的应用中生效。

安全指南还提醒，持有某个状态标识符不等于通过身份认证。工作流或购物车编号只是指出需要检查的对象，不能证明谁有权使用它。

让批准对应具体内容，并由系统强制执行

提出预约时，应在确认前向客户展示服务、时区、日期、价格和取消条件，并记录获批内容。如果重要细节变化，应重新取得批准。模型生成的“已批准”标记，不能证明客户同意。

应把准备提案与正式确认分开。如果保存草稿会创建记录或发送通知，它已经是写入操作，必须纳入权限设计。没有针对这些具体条件的必要批准，服务器就应拒绝作出承诺。

我们的智能体可调用系统服务从读取工具开始，最后才添加会产生义务的操作，不可逆操作需要客户确认。我们的试点开发对系统写入、客户消息和资金操作另有人工批准要求。一般架构示例不会扩大合同约定的范围。

上线前测试拒绝与恢复

使用测试账户和记录。把预期结果与实际结果保存在一起，让下一位开发人员也能复现测试。

限制权限范围，设置凭证有效期，并实际测试权限撤销。按安全边界需要分开凭证，但每项工具都使用不同登录并非通用要求。设置超时、重试上限和每个调用方的配额。写入操作应采用稳定的操作编号，由服务器处理重复请求，不能依赖模型记住自己已经尝试过。

记录调用方、操作、权限判断、相关批准编号和结果。隐藏秘密信息及不必要的个人数据，确定谁能读取日志、保留多久。指定能下线工具并核对不确定结果的负责人。面向采购审查的试点指南说明如何让这些责任可供核查。

我们的公开示例能证明什么

2026 年 10 月 9 日，我们检查了 mcp.strataigize.com 的 tools/list、公开授权元数据及 auth.md。工具列表公布了七项公开读取工具和一项经过认证的 request_growth_audit，用于申请免费的增长咨询。名称虽然沿用旧称，但申请的是咨询，不是付费的 AI 机会审计。

这项申请属于写入操作。文档要求必须有某位具体的人提出请求，并说明提交后由人审核，不会自动预约。文档也明确区分了软件客户端的开放注册和对个人身份的核验。

这次检查确认的是已公开的接口与规则。我们没有提交申请，也没有在此次审查中测试其安全性。工具列表不能证明外部使用量或销售。

委托开发前，写下第一项客户任务、允许的数据、禁止的操作、批准节点、失败测试、负责人和工具下线程序。除了正确完成的客户任务，还要衡量拒绝、例外和人工审核时间。原始调用量包含重试和失败，不是成功次数。AI 咨询可以在委托集成开发前，帮助明确这一范围。