织信开发日志 18：从 informat-skills 看织信如何把平台能力交给 AI Agent
上一篇我写到，织信 Skill 的目的，是把织信平台能力暴露给 AI Agent 调用。
这一篇可以更具体一点。
不是抽象地讲"AI 能调用工具"，而是直接看 informat-skills 这套 Skill 到底在暴露什么能力。
它不是一个提示词合集。
它更像一份平台能力地图。
GitHub - informat365/informat-skills: informat-next-ai-skills · GitHub
AI Agent 读完以后，不只是知道"织信是低代码平台"，而是知道：
我能查团队。
我能查应用。
我能查对象。
我能查字段。
我能操作用户、角色、权限。
我能进入设计器上下文。
我能基于平台方法继续执行下一步。
这就是 Skill 和普通产品介绍最大的区别。
产品介绍告诉人"这个平台能做什么"。
Skill 告诉 AI Agent "你现在可以调用什么能力，以及调用前后要注意什么"。
第一类：Workbench，工作台能力
AI Agent 进入织信以后，第一件事不是创建字段，也不是生成页面。
第一件事应该是理解当前用户所在的工作环境。
这就是 Workbench 相关能力的价值。
它对应的是工作台层面的上下文：当前有哪些团队、有哪些应用、用户能进入哪些空间、应用列表如何组织。
对人来说，这些信息可以通过页面看到。
但 AI Agent 不能靠猜。
它需要通过明确的方法拿到这些上下文。
比如用户说：
"帮我优化一下项目管理应用。"
AI Agent 不能直接假设项目管理应用存在，也不能假设当前账号有权限操作它。
它应该先查工作台。
找到团队。
找到应用。
确认当前用户能不能进入这个应用。
然后才进入后续设计动作。
所以 Workbench 能力解决的是入口问题。
没有这一层，AI Agent 很容易在一开始就走错空间。
第二类：Team，团队和权限能力
企业系统里，AI 不能绕过用户权限工作。
这是我反复强调的一点。
Team 相关 Skill 暴露的是团队、成员、角色、权限这些能力。
它让 AI Agent 知道，当前操作不是发生在一个孤立页面里，而是发生在一个有组织边界的团队里。
谁是管理员。
谁是普通成员。
哪些角色能设计应用。
哪些成员只能使用运行端。
哪些动作需要更高权限。
这些信息决定了 AI Agent 能不能执行下一步。
如果用户没有权限发布应用，AI 也不应该替他发布。
如果用户只能查看某个表，AI 也不能借工具调用去修改它。
Skill 把平台能力交给 AI Agent，同时也必须把权限边界交给它。
否则 AI 就不是在替用户工作，而是在绕过用户工作。
第三类：Designer，设计器能力
Designer 是最关键的一层。
因为低代码平台真正的结构，大多在设计器里。
应用对象、数据表、字段、页面、视图、流程、自动化、脚本，这些都属于系统结构。
AI Agent 如果只是聊天，它不需要碰这些东西。
但如果它要真正帮用户搭应用，就必须理解设计器能力。
比如：
- 当前应用有哪些对象；
- 某个对象有哪些字段；
- 字段类型是什么；
- 页面绑定了哪个对象；
- 视图展示了哪些字段；
- 自动化监听了什么事件；
- 脚本函数能被哪些动作调用。
这类能力的价值非常大。
因为 AI Agent 生成应用时，最容易犯的错不是少生成一个字段，而是生成了一个和现有系统不一致的结构。
Designer 能力让 AI 先看到当前结构，再决定怎么改。
它把"凭感觉生成"变成"基于当前应用继续建设"。
这也是织信 Skill 里最像工程底座的一部分。
第四类：User，用户和运行端能力
应用设计出来以后，最终还是要给用户使用。
所以 Skill 不能只暴露设计端能力，也要暴露运行端和用户相关能力。
用户是谁。
用户能看到哪些数据。
用户属于哪些团队或角色。
当前操作会不会影响真实业务数据。
这些问题不解决，AI Agent 就只能停留在"搭建工具"的层面。
但企业应用不是只有搭建。
它还要运行。
运行端的权限、数据范围、用户身份、记录操作，都会影响 AI Agent 的判断。
比如用户说：
"帮我查一下这个项目的延期原因。"
这不是设计器任务。
AI Agent 要进入运行端语境，查项目记录、任务状态、工时、风险和变更历史。
如果它没有用户和数据边界，就很容易查到不该看的内容，或者给出没有依据的判断。
所以 User 能力解决的是运行时身份问题。
AI Agent 不是一个超级管理员。
它应该继承用户的上下文和边界。
第五类：Common，通用基础能力
除了业务模块，Skill 里还需要一层通用能力。
比如文件、请求、通用查询、上下文解析、状态判断、错误处理。
这些能力看起来没有 Designer 那么显眼，但很重要。
AI Agent 真正执行任务时，经常需要在多个能力之间切换。
先查应用。
再查表。
再查字段。
再判断权限。
再创建或修改结构。
过程中任何一步失败，都要能知道失败在哪里。
Common 能力就像胶水。
它不一定直接代表某个业务对象，但它让 AI Agent 的动作可以串起来。
没有这层通用能力，每个工具调用都会变成孤立动作。
有了它，AI 才能把一次复杂任务拆成可追踪的步骤。
这套 Skill 真正暴露的不是接口，而是平台结构
如果只看表面，informat-skills 像是在列方法。
但我觉得它更重要的意义，是把织信的平台结构暴露给了 AI Agent。
Workbench 让 AI 知道自己在哪个工作空间。
Team 让 AI 知道权限和组织边界。
Designer 让 AI 知道系统结构如何被创建和修改。
User 让 AI 知道运行端身份和数据边界。
Common 让 AI 能把这些能力串成一次完整操作。
这几类能力合在一起，AI Agent 才不只是一个会回答问题的助手。
它开始具备平台操作者的基本条件。
它知道入口在哪里。
知道当前有什么。
知道哪些能查。
知道哪些能改。
知道改之前要确认什么。
知道失败以后要怎么反馈。
这就是我理解的织信 Informat Skill。
它不是给 AI 背产品说明。
它是在把织信拆成 AI Agent 可以安全调用的能力层。
AI Agent 真正进入低代码平台，靠的不是一句"你是低代码专家"。
靠的是平台愿不愿意把自己的能力拆开、命名、约束，并暴露给 AI 调用。
informat-skills 这件事的意义就在这里。
它把织信从一个"人通过页面操作的平台"，向"AI Agent 可以按规则操作的平台"推进了一步。
这一步并不只是技术实现。
它会反过来影响平台设计。
因为一旦要把能力暴露给 AI，就必须重新审视每个能力的边界：
这个方法能不能被 AI 调用？
调用前要不要先查询？
参数从哪里来？
失败怎么返回？
权限怎么判断？
高风险动作要不要确认？
这些问题回答清楚以后，平台本身也会变得更清楚。
Informat Skill 不只是 AI Agent 的入口。
它也是重新整理低代码平台能力边界的一次机会。