标签

为企业AI Agent、MCP和CLI构建安全边界

发布时间:2026-04-29 12:50来源:微信阅读:6

企业引入Agent时,通常首先担忧的是模型可能给出错误答案。

然而,一个更棘手的问题在于,当Agent开始能够自主执行任务时。

以往,AI助手最多不过是说错一句话。如今,一个Agent连接上MCP后,便能查询系统、调用接口、修改数据;若再进一步接入CLI,则能读取文件、执行命令、修改代码、触发部署。

这已不再是简单的聊天机器人问题。

这关乎产品边界的界定。

企业Agent的安全防护重点,已从防止模型出错,转移到重新定义:机器在何种程度上可以代表人类执行操作。

在传统软件中,用户点击按钮,系统执行相应动作,责任链条清晰明了。

当Agent融入业务系统后,中间多了一个判断环节:

用户输入指令,模型理解其意图,然后决定是否调用工具,最终由工具来改变系统状态。

风险也在此发生转变。

普通问答失误,尚可纠正。推荐错误,可能影响决策。而动作错误,则会直接干预业务流程。

例如:

将一个无效客户信息录入CRM; 将内部敏感资料泄露给未经授权的人员; 在代码仓库中修改了不应更改的文件; 为客户创建了错误的工单; 在未获得确认的情况下触发了外部通知。

这些情况已不太像是“AI幻觉”的范畴。

它们更像是权限管理、流程控制以及企业治理方面的问题。

因此,产品负责人需要调整思考角度:不要急于询问Agent能做什么,而应先明确它默认情况下可以做到哪一步。

MCP的价值显而易见:它使得外部系统能够被Agent当作工具来调用。

这对SaaS公司尤为重要。你的产品能力不再局限于通过网页、API或集成平台对外开放,还能被客户自有的Agent、Claude、ChatGPT或内部助手直接调用。

产品易出错之处也在此体现:许多团队将MCP简单理解为“将接口开放出去”。

这种做法过于粗糙。

从产品设计的角度看,MCP的能力至少应分为三个层级。

第一层是读取能力。例如:公司信息、产品资料、帮助中心内容、公开案例、服务目录等。

这一层级旨在让Agent理解你的产品定位、服务范围及相关限制。其风险较低,适合优先开放。

第二层是判断能力。例如:服务推荐、客户分层、合作伙伴匹配、FAQ归纳、方案建议等。

这一层级不直接修改数据,但会影响客户的下一步决策。因此,产品上需明确说明:此为系统建议,并非商业承诺。

第三层是执行能力。例如:创建潜在客户、发起人工接管、创建工单、同步CRM数据、发送通知等。

这一层级最为敏感,因为它会直接改变系统状态。切勿将其与前两层能力混杂在一个所谓的“全能连接器”中。

我更倾向于将产品层面拆分为两个部分:

MCP Public:仅提供读取和低风险判断能力,用于让外部Agent理解产品。MCP Actions:负责写操作和业务执行,在明确授权下推进流程。

如此划分,客户在进行授权时能清晰理解,销售人员在介绍企业版产品时也能准确阐述。

如果说MCP是将“企业系统转化为Agent的工具”,那么CLI Agent则是“让Agent深入工作现场”。

开发环境、代码仓库、本地文件、命令行、脚本、测试、部署流程等,这些区域本身就拥有强大的执行权限。

Agent一旦进入CLI环境,问题就不仅仅是“能否调用接口”:

它能否读取此目录下的文件?能否修改该文件?能否连接网络?能否安装依赖库?能否执行危险命令?能否在用户未察觉的情况下连续执行一系列操作?

许多产品在此方面采取了两个极端做法:

要么每一步都弹出确认提示,导致用户因厌烦而选择全盘放开; 要么提供全自动模式,表面上看起来很高效,但却让企业IT和安全团队难以接受。

这两种方向都不够稳妥。

CLI Agent的权限体验,应采用分级模式。

例如:

只读模式:仅限于检索、阅读和解释信息。工作区模式:允许修改当前项目,但不能超出指定目录范围。受控执行模式:可执行测试和构建任务,但高风险命令需经用户确认。全自动模式:仅适用于可信项目、可信用户、可信任务,且必须包含审计和回滚机制。

产品负责人应关注的是,用户能否形成稳定的预期,而不仅仅是弹窗数量的多少。

用户应该清楚地知道:当前Agent是在进行读取、提供建议,还是在替自己执行操作。

企业Agent的授权体验,绝不能设计成“连接时一次性授予所有权限”。

这种模式在消费者产品中已显不妥,在企业场景下则更为危险。

更优的方案是:先建立连接,再逐步授予权限。

首次连接时,仅申请基础的只读权限。用户可以查看到Agent能够读取哪些信息、调用哪些低风险能力。

当Agent首次需要执行操作时,例如创建潜在客户、同步CRM数据、发起工单等,则触发二次授权。

当操作影响范围更大时,例如发送外部消息、修改系统配置、删除数据等,则必须经过审批流程。

这里的关键不仅在于“增加一道确认环节”,更在于确认提示信息必须清晰易懂。

避免使用:

tool: create_lead, scope: write_leads

用户对此并不关心。

应当改为:

将创建一条销售线索,并写入联系人、公司名称、需求摘要等信息。