AI 时代,企业对软件(采购 or 自建)有了什么新的要求

AI混子-俊 · 深度观察

深度 · AI × 企业软件

AI 时代，企业对软件（采购 or 自建）有了什么新的要求

不是加一个 MCP 接口，而是把治理从人的世界延伸到 agent 的世界

过去员工用软件，就是打开网页、点菜单、填表单。GUI 是唯一的入口。

现在多了一个入口：Agent。员工开始习惯把 agent 当同事使——遇到问题先描述任务，而不是先想"该登哪个系统、点哪个菜单"。

举个例子。某个员工说自己 XX 月份的考勤数据有问题。HR 能不能直接跟 agent 说一句"帮我查一下这位员工这个月的考勤明细，核对异常记录，出一份核查报告"？然后 agent 自己去考勤系统拉数据、核对规则、生成报告，HR 审一眼就能回复员工。

这里省掉的是 HR 查询、确认、整理报告的时间；员工拿到的，还是一份比口头解释专业得多的书面答复。

要让这个场景成立，前提是：系统能被 agent 调用。这就是 AI 时代企业采购或自建软件时，新增的那一整条要求。

但"能被调用"四个字，展开来是一整套东西。下面一条条说。

01

先校准一下：这个变化到底有多真实

先别急着说"全员都要用 agent 了"——现实是，只有少数 AI 重度用户养成了这个习惯，大多数普通员工还在点 Excel。

更准确的判断是：趋势明确，渗透尚早，所以要按场景切，而不是一刀切。

1.高频 + 多步骤 + 跨系统的信息整合（查数据、核对、出报告）→ agent 入口是必选项。这类工作占 HR、财务、运营这些岗位相当大比例的日常。

2.低频 + 简单的查询操作→ GUI 点两下反而快，agent 是可选项，别为了上而上。

所以采购或立项时的判断标准不是"别人都有我也要有"，而是：这个系统支撑的工作里，有多少属于第一类？占比越高，agent 友好就越紧迫。

02

要求一：接口要对 agent 友好，而不只是"支持 MCP"

在采购清单上写一句"需支持 MCP / CLI 调用"，是最容易落成的形式主义。同样号称支持 MCP 的两个系统，agent 用起来体验能差 10 倍。差别在哪：

1. 面向任务设计，不是面向数据库设计

给 agent 一组"动词"：查询员工考勤(工号, 月份, 异常类型)、导出考勤异常清单(月份, 部门)——而不是把 100 个细碎的 CRUD 接口裸露出去让它自己拼。工具数量控制在 10~20 个以内，太多了 agent 会选错工具。

2. 工具描述就是 agent 的"菜单"，要当正式文档写

每个工具叫什么、干什么用、每个参数什么含义、什么场景不该用它—— agent 全靠这些描述来决定调不调、怎么调。描述含糊，agent 就乱调。这是 API 时代"文档随便写写"到 Agent 时代"文档即功能"的转变。

3. 报错要能帮 agent 自我纠错

对比两种报错：

×  "参数错误"（agent 只能瞎猜，然后反复失败）

√  "employee_id 应为 8 位工号，你传入的是姓名；请先调用"工号查询"接口换取 ID"（agent 下一步就知道怎么办）

后一种报错，等于把客服的活儿写进了接口里。

4. 返回值要结构化、有节制

字段名语义化（用 attendance_date 别用 a1）；必须支持分页和条数上限——不然一次查询返回几万行，直接把模型的上下文撑爆。

5. 能力暴露的架构：一套 API，两种壳

这一条回答的问题是：软件到底以什么方式把能力交给 agent？先把分层架构画出来：

自下而上看：

1.统一 API 层是地基，也是第一种暴露方式。权限校验、审计日志、业务规则只在 API 层实现一次，它本身就服务于"系统对系统"的集成场景。API 没做干净，上面包什么都白搭。

2.CLI 是包在 API 上的第一种壳，服务终端型 agent。像 Claude Code 这类在终端里干活的 agent，天生就会执行 shell 命令——对它们来说，一个设计良好的 CLI 就是调用系统能力的最自然方式，不需要 MCP。gh、docker、ffmpeg 这类工具，终端 agent 直接用 CLI 就操作得很好。当然 CLI 同时也服务于人：技术人员的脚本化、批处理、管道组合。

3.MCP Server 是包在 API 上的第二种壳，服务对话式 agent。聊天界面里的 assistant（Claude、ChatGPT 这类）不能执行任意命令，必须通过标准协议来发现和调用外部工具—— MCP 就是这个协议：工具自动发现、结构化的参数和返回值、标准化的 OAuth 鉴权，全是规范好的，agent 不需要学你家的 CLI 语法。

所以这套架构的选用原则是：按 agent 的形态选壳，而不是二选一、更不是都做。

开发者向的系统（DevOps、代码、数据工具）→ 优先做 CLI，终端型 agent 直接受益；员工向的业务系统（HR、考勤、财务）→ 优先做 MCP，因为员工用的是对话式 agent。

最大的反面坑：CLI 和 MCP 各自直连数据库、绕过 API 层各实现一套逻辑——结果权限和审计出现两份不一致的实现，agent 走哪条路就适用哪套规则，后面要求二讲的权限治理直接失效。壳必须是薄壳，只做"翻译"（把 API 翻译成命令/工具），不做业务。

6. 验收方式：别看宣传页，拿真实任务跑

选三五个真实岗位任务（比如上面那个考勤核查），让 agent 在 sandbox 里现场跑一遍，跑得通才算"支持"。就像以前采购软件要看 demo，现在要看agent demo。

03

要求二：权限—— agent 以谁的身份干活

这是开放 agent 调用前最大的坑，很多企业的权限体系是靠"前端不展示"兜底的：接口返回全量数据，界面只给人看他该看的。一旦让 agent 直接调接口，等于把员工权限范围外的数据一口气全喂给了模型。

核心原则：agent 永远以员工本人的身份干活，权限跟着人走，且只能是人权限的子集

具体做法：

1.身份要传递。agent 调用时必须携带"我代表哪位员工"的凭证（OAuth token 里带用户身份），系统按这位员工本人的权限过滤返回。绝对不能给 agent 发一个超级账号或企业级 master key——那是把整个系统的钥匙交出去了。

2.按岗位配置"agent 可用能力清单"。agent 能调的范围应该是员工权限的子集：比如 HR 助手只开放考勤查询，不开薪资接口——哪怕这位 HR 本人在界面里能看薪资。默认最小化，跑稳了再扩。

3.开放前做一次"前端兜底型权限"清查。把那些"接口全量吐、界面裁剪显示"的接口找出来，要么在后端补上权限过滤，要么在 MCP 网关层做字段裁剪。这个清查不做，开放 agent 调用就是裸奔。

4.审计日志记三件事：哪个员工、通过哪个 agent 会话、调了什么接口返回了什么。要能区分"人点的"和"agent 干的"。出了问题能回放、能定责。

5.责任划分写进制度：agent 是工具，它执行操作的责任归使用它的员工（或审批人）。这话要提前说清楚，不然出第一次事故就会吵翻天。

04

要求三：数据出域——过模型之前先想清楚

考勤、薪酬、身份证号，这些是敏感个人信息。走 agent 对话，意味着数据要经过大模型。模型部署在哪，数据就到哪。这一条在国内经常是一票否决项，必须提前设计，按数据敏感级分三档处理：

第一档：最敏感数据 → 私有化部署模型

最敏感数据（薪酬、身份信息、涉密内容）→ 私有化部署模型，数据不出企业边界。金融、央国企基本没得选。

第二档：一般业务数据 → 合规云端 API

但合同要写死四件事：

1.  模型和数据落在哪个机房（境内）

2.  对话日志存什么、存多久、谁可查

3.  数据是否用于模型训练（必须为否）

4.  有没有下游子处理者

依据是《个人信息保护法》《数据安全法》和生成式 AI 相关规定，采购时把这四问写进合同附件。

第三档（性价比最高的一招）：网关层脱敏 + 上下文最小化

在 MCP 网关上做脱敏：身份证号、手机号、工资数字自动打码；同时只把完成任务需要的字段喂给模型——考勤核查只需要日期、打卡时间、异常类型，不需要家庭住址。很多任务其实根本不需要敏感字段的原文，脱敏之后照样干得成。

实际落地通常是按数据分级路由：普通数据走云端 API，敏感数据走私有化或先脱敏，而不是一刀切全私有化（成本受不了）。

进阶问题：员工拿自己的第三方 agent 连公司的 MCP 服务，怎么办？

上面的方案有个隐含假设：模型调用走的是公司认可的通道。但 MCP 服务一开放，就会出现一个真实的漏洞——员工在自己电脑装个 Claude Desktop（或任何支持 MCP 的 agent），填上公司 MCP 地址、配上自己申请的第三方模型 key，连进来了。系统照样响应、数据照样返回，只是数据流向变成了：公司系统 → 员工本地 agent → 员工自选的第三方 LLM。数据出域了，公司毫无感知。

这个问题的本质是：员工用什么客户端你永远管不住，但服务端接受谁的连接，你完全说了算。所以控制点必须全部做在 MCP 服务侧，指望"规定员工只能用 XX"是没用的。分五层做：

1.网络收口：MCP 服务不暴露公网。部署在内网或 VPN 之后，员工进了公司网络才能连，云端 agent 的请求根本到不了门口。这是最硬的一条，一大半风险在这层就消掉了。

2.客户端白名单：光"有身份"不够，还得"是批准的客户端"。OAuth 鉴权（确认是哪位员工）之上再加一道：只接受公司批准的 client_id。企业自建 agent 门户、签了数据处理协议的企业版客户端各自持有正式凭证；员工个人安装的 agent 拿不到批准凭证，连上直接拒。新客户端要走注册审批，默认拒绝。

3.入口收口：把官方 agent 入口做到"员工不想绕"。前两层是堵，这层是疏。最可控的架构是公司统一提供 agent 入口——模型调用在公司侧、脱敏在公司侧、日志在公司侧，员工的需求都能在这个入口满足。员工绕过官方入口最常见的原因就是"官方的不好用"；入口不够好用，再严的封锁都会被用脚投票绕开。

4.数据层兜底：脱敏不认通道，谁来都脱。万一真被绕过（比如批准的客户端被员工改配了自己的模型 key），MCP 网关上的脱敏和字段裁剪是最后一道防线——敏感字段在离开系统之前就打码了，不管下游接的是谁。

5.审计发现：盯"不像正常使用"的信号。日志除了记"谁调了什么"，还要记"从哪个客户端、什么来源 IP"。异常信号包括：白名单外的 client、非公司网段的 IP、单人调用量突然暴涨、非工作时间批量查询。发现绕过行为按信息安全制度处理——制度要提前写明"使用未批准客户端连接公司系统"属于违规。

最后诚实说一句边界：只要员工能看数据，截屏、拍照、复制粘贴这类泄露就存在，技术拦不住。这套方案的目标不是物理杜绝，而是把"无意的、大规模的、自动化的出域"全部堵死，把"主观故意的小规模泄露"留给审计和制度去管。这是所有企业数据安全的通用边界，不是 MCP 特有的。

05

要求四：读写要分级——读放行，写设卡

开头的考勤例子是纯读场景，低风险。但真实工作总有写操作："帮我把这条考勤异常标记为已核实"、"帮我提交调休申请"。agent 改错一条数据就是事故，所以读和写必须区别对待：

原则：读操作在权限内默认放行；写操作默认拦截，按风险分级放。

1.低危写（生成报告、存草稿、给自己发提醒）→ agent 直接执行。

2.中危写（修改业务数据、提交审批）→ agent 把要执行的操作准备好，人点一下确认再落库。

3.高危写（批量修改、删除、涉钱涉薪）→ agent 只能给出建议和清单，由人来操作，或者双人复核。

另外三个技术细节，都是踩过坑才知道的：

1.写接口必须防重复提交（幂等）。agent 有重试机制——第一次超时它会自动再发一次，接口不幂等就会把一条调休提交成两条。

2.给写操作设上限阈值。单次批量修改超过 N 条、涉及金额超过 X，强制转人工。宁可慢，不可错。

3.写操作留双段痕迹："agent 建议了什么"+"谁批准的"。回溯时能分清是模型出的错还是人批的错。

落地节奏上，建议先只读跑三个月，把信任和审计流程跑顺，再逐级开放写。一上来就全开，是在拿生产数据赌运气。

06

要求五：存量系统和 SaaS 怎么办——厂商该给什么支持

前面说的是"应该长什么样"。现实是企业手里一堆存量系统、采购的 SaaS，厂商不配合就寸步难行。这一节从厂商视角讲：从成本最低到完全支持，分四档，采购方可以直接拿去当谈判清单。

Level 0：什么都不给（现状，最差状态）

客户只能用 RPA 模拟人点界面来"曲线救国"。脆弱——厂商一次改版就全崩；而且通常违反服务条款，出了数据事故责任全是客户的。这是双输状态，不展开。

Level 1：开放标准 API + 按人鉴权（成本最低的合格线）

厂商要做三件事：REST API + 完整文档 + 测试环境（sandbox）。

其中鉴权方式是生死线：必须支持 OAuth 2.0 授权码模式，token 跟具体员工绑定（agent 代表谁，就拿谁的 token），并且支持细粒度 scope（这个应用只读考勤、不可写、不可碰薪资）。

反面案例：只发一个企业级 master API key 的"开放"，等于没开放——没法按人控权、没法审计、token 一泄全系统裸奔。

对成熟 SaaS 来说，内部接口本来就是现成的，Level 1 主要是"整理 + 开放 + 补鉴权"的工作，成本不高。到了这一层，客户就可以自己在前面搭 MCP 网关，把 SaaS 包进 agent 体系。

Level 2：官方 MCP Server（中等投入，体验分水岭）

厂商自己出官方 MCP 服务，把高频任务封装成十几个面向任务的高质量工具（呼应要求一：好的工具描述、好的报错文案），鉴权直接复用 OAuth——新版 MCP 规范的授权章节就是按 OAuth 2.1 设计的。

对厂商是"一个小组、一两个季度"的投入；对客户的价值是省掉自建网关的维护成本，而且工具质量远高于客户自己裸包接口。

Level 3：企业级深度支持（完全体）

管理后台可配置：哪些岗位允许 agent 调用、各岗位能调哪些工具；审计日志区分"人 vs agent"调用，可导出回传给客户的安全团队；数据分级：agent 通道默认脱敏，白名单字段才给原文。

agent 流量单独的限流和计费—— agent 的调用量比人大几个数量级，按人头 API 套餐一刀切会出事故；SLA 和事故责任划分写进合同。

给采购方的行动建议：把上面四档写进选型清单和合同—— API 是否按人鉴权、有没有 sandbox、官方 MCP 的路线图、审计日志能否区分 agent、agent 调用怎么计费。厂商现在重不重视不重要，采购标准前移，厂商就会跟进——这和当年"必须支持 SSO、必须支持开放 API"是同一个剧本。

07

最后：这不只是省时间，是以前做不到的事

如果把 agent 入口的价值只框定为"节省查询和整理报告的时间"，去跟老板算人力账，很可能算不平。它真正的增量，是几件 GUI 时代根本做不到的事：

1. 跨系统的一句话整合

"把这个月迟到超过 3 次的员工列出来，连带他们上个月的排班"——以前要在考勤系统和排班系统各导一次 Excel 再人工拼。agent 入口让跨系统整合第一次变成员工自己张嘴就能办的事，不用提需求、不用等 IT 排期。

2. 零培训门槛

新入职的 HR 不用背"考勤异常在哪个菜单、审批流从哪发起"，自然语言就是操作手册。系统越多越复杂的企业，这一条价值越大—— agent 成了所有系统的统一前端。

3. 服务质量下限的整体抬升

以前熟练 HR 和新手给出的答复质量天差地别；以后 agent 生成的核查报告让每个 HR 都能给出数据齐全、口径统一的答复。对员工来说，得到的回复更专业也更透明。

4. 长尾需求的当天自办

各业务部门那些一次性的、"帮我拉个数据核对一下"的小需求，占了 IT 部门大量工单。这类需求员工自己问 agent 当天就能消化掉。

5. 过程数据的沉淀

每一轮"描述任务 → 调用系统 → 产出结果"的对话，都是一份"这个岗位真实怎么干活"的记录。积累下来，企业第一次能看见各岗位的真实工作流——反过来指导流程优化和下一次系统采购。这是 GUI 点击日志永远给不了的东西。

AI 时代企业对软件的新要求，不是加一个 MCP 接口，而是把"谁能用、用什么数据、能读还是能写、出事算谁的"这套治理，从人的世界延伸到 agent 的世界

谁先把这套想清楚，谁的系统就先一步从"给人用的工具"变成"给组织用的能力"

- END -