一、Agent 正在大规模进企业，但「敢不敢让它碰系统」成了刹车
产业数据已经不再抽象：微软披露数以万计的企业在管理数千万个 AI Agent，法国 IT 服务商 Atos 一家就在管 1.9 万个；Salesforce 的 Agentforce 累计完成了 24 亿个「agentic work units」——AI 真正替企业完成一件工作的次数。
但与此同时，安全案例也在刷新认知。36氪 2026 年 9 月 8 日转载的一篇文章讲了几个实验：骗子把指令藏在网页屏幕外 -9999 像素的位置，人类看不见、Agent 读得到；研究人员拿 26 个模型测一个假网站，GPT-5.4、Claude Sonnet 4.5 在只看到假站时都把它当成了可信入口；还有人伪造 Python 库诱导 Agent 付 3 美元买「软件许可证」，Llama、Gemini 共 4 个模型真的执行了付款。安全公司披露的 EchoLeak 漏洞更直接：员工不用点击任何链接，Copilot 处理邮件时，藏在邮件里的指令就能诱导它把内部信息带出去——「有了 Agent 帮忙，钓鱼邮件都不用你点击了」。
安全圈与产业界正在形成一个共识：Agent 越接近真实业务，治理越要前置。网易智企 6 月给 CEO 们发了一份检查清单，把内容边界、权限边界、数据边界、操作边界、审计记录和责任归属列为上线前必须回答的问题（出处：网易智企《安全合规治理不应等问题发生后再补》2026-06-17）。落到自己公司，问题会浓缩成一句很具体的话：让 AI Agent 操作业务系统之前，你怎么保证它不会乱建乱改数据？出了事，查得到是哪次操作、哪个账号干的吗？
二、为什么多数系统接不住 Agent
想让 Agent 干活，先得有接口。但大部分企业系统天生不是给 AI 用的：
- 契约靠人写人读的文档：接口文档由人维护，版本一升级就漂移，Agent 按旧文档调新接口必然出错。有厂商吐槽过这个现状：「AI 不知道有什么内部系统、如何接入」（出处：火山引擎开发者社区 2025-06-12）。
- 开放裸 API 却没有校验：Agent 的幻觉会直接变成脏数据——字段名拼错一个字母，一张坏表单就进了库。AI 接入的协议层（如 MCP）解决了「怎么连」，但正如一篇治理文章提醒的：它同时扩大了攻击面，企业必须配套认证机制和治理可见性，否则「连得上」不等于「敢让它操作」（出处：知乎《当MCP成为AI Agent的”企业接口”》2026-07-22）。
- 审计缺失：AI 做了什么只能靠猜。行业对 AI 审计的要求是能回答四个问题：什么数据进来了、输出了什么、系统做了什么、谁批准的（出处：Collibra 2026-06-24）——多数系统一条都答不上。
三、GTS 的做法：把 AI native 做成机制，而不是口号
GTS 是一个多租户、元数据驱动的「表单+审批流」平台，走的是另一条路：既然 AI Agent 要进业务流程，那就从系统层面回答好三个问题——看得懂、改不坏、赖不掉。
① 看得懂：机器可读契约，Agent 自己拉取，永不漂移
GTS 提供两个公开只读端点，无需登录，任何 Agent 启动时都能自己拉取：
/discovery/routes：当前全部 58 个 API 端点自动导出。后端每加一个路由，列表自动多一条——写作当天实测已是 58 条，任何静态文档都追不上这个更新速度。
/discovery/contract：配置域契约——认证方式、响应信封、多租户纪律、12 种字段类型及其附加属性、流程节点属性、单据状态机、审批动作枚举、字典用法。
因为契约从系统实现自动导出、与代码同源，它不会像人手维护的文档那样过时。AI 学的是系统自己的配置语言，不是一份翻译稿。（浏览器打开 https://www.geeyo.com/s/gts/api.php?route=/discovery/contract 当场可验。）
② 改不坏：服务端强校验，幻觉写不进数据库
表单 schema、流程 nodes 在落库前全部经服务端校验：字段类型必须在白名单内、字段 key 唯一且合法、select 必须有选项、流程节点名唯一、审批人规则必须合法。非法配置直接返回 400，并带精确到位置的报错——比如把 required 拼成 requred，会收到 schema_json[0] has unknown key(s): requred。Agent 收到报错可以自己修正重发；非法内容根本不落库。模型幻觉再离谱，也污染不了数据库。这正对应治理清单里那条底线：「系统接口返回异常时，不能反复提交或绕过校验」——GTS 把这条做死在了服务端。
③ 赖不掉：全操作审计，人与 Agent 一视同仁
每一次管理/变更写操作都记入审计日志：租户、操作者账号、动作、对象、IP、User-Agent、摘要，操作者自动从 token 解析。无论是人还是 Agent、用的是哪个账号、做了什么，全部可回看。前面说的四个问题（什么进来了、输出了什么、系统做了什么、谁批准的），在这里逐条有答案。
④ 官方直接把「Agent 上岗说明书」做成了可下载的技能包
GTS 把「AI 怎么操作这套系统」打包成一个官方技能包 gts-operator，下载地址：https://www.geeyo.com/s/gts/dist/skills/gts-operator.zip 。支持 skills 机制的 Agent（Claude Code / Codex 类）装上之后，用自然语言就能完成整套管理操作：帮客户开通租户并配管理员、维护组织架构与人员、配置表单与审批流（字段类型 / 条件分支 / 审批人规则）、发起业务单据、执行审批（同意 / 驳回 / 转办 / 加急）、查询与导出。它采用「动态发现」模式——先拉取 discovery 契约再动手，后端演进时技能无需手改。关键设计：Agent 与人类走的是同一套 API、同一份校验、同一份审计，系统没有给 AI 开任何后门。官方已用它跑通「注册租户→建组织→配表单/流程→发起单据→审批」的全链路验证。
四、三个值得展开的设计取舍
为什么「校验+审计+隔离」三件套缺一不可？ GTS 的设计哲学是「安全是前提，不是功能」：校验保证非法内容不落库，审计保证每个操作可追溯，行级多租户保证跨租户访问一律 404。三件事同时存在，才敢把写操作开放给 AI——缺了任何一件，开放 API 给 Agent 都是在裸奔。
为什么契约能精确到字段级？ 因为 GTS 本身是元数据驱动的：表单、流程、字典都是数据、都是配置。契约描述的正是系统实际运行的语言——字段类型、校验规则、状态机与实现同源，不存在「说明书和实物是两回事」。这是 AI native 能落地的地基，也是它和「事后补文档」式集成的根本区别。
边界在哪里？ GTS 的 AI 能力覆盖表单+审批这类配置化业务域。它不是通用 BPM 重引擎，也不是 Agent 托管平台——它解决的是企业接 Agent 最前面那道坎：接得进、改不坏、赖不掉。
五、十分钟自己验证
三步就能验证上面说的每一句：浏览器打开 https://www.geeyo.com/s/gts/api.php?route=/discovery/contract 看契约长什么样；下载 gts-operator.zip 装给手边的 Agent，用自然语言让它开一个租户、配一张报销单；再到演示站 https://www.geeyo.com/s/gts/ 注册、走完一张单的审批。AI native 是真机制还是噱头，动手十分钟就有答案。