为什么由智能体来建

第 1 课 · 共 6 课 约 8 分钟

智能体在分支上构建本体；建与用分开；作者由凭证决定，审核按 review 或 yolo 处理。

本课目标

读完这一课，你将能够

  • 说出智能体怎样构建本体（Ontology），以及 review 与 yolo 怎样审核
  • 说出「建」与「用」为什么是两套工具，各自能做什么
  • 判断一次请求的作者身份，解释智能体直接写 main 为什么会得到 409 branch_required

由智能体写定义

上一门课讲了权限与治理，分支和提案是其中把关的机制。这一门讲的是：谁来写这些改动。

本体的构件包括 Object Type、Link Type 和 Action。平台记录权限与审计。智能体在分支上写定义，再开提案。review 由人审核；yolo 允许有权修改本体的贡献者批准，检查通过后自动合并。

通用做法AIDC 的做法
谁发现缺口人，靠经验和需求会议智能体，靠答不出的问题和新的数据源
谁写定义人，在管理界面里智能体，写成目录里的定义文件，先在分支上试
谁审核、合并有权限的人review 只收本组织 developer 的网页登录；yolo 也收合格 Key
构件、规则、权限、审计一套同一套，一样不改

为什么让智能体来建？因为最先发现「不够用」的，是每天拿它干活的智能体。示例工厂的采购员一周里三次问「哪些供应商在哪些物料上晚了」，采购智能体三次都答不出。它比任何人都清楚缺了什么。

让它自己写、自己测，再交给人审，既比等人想起来快，也比让它随手改现网安全。这个例子会贯穿整门课。

建与用是两套工具

智能体对本体做两类事，工具和规矩都不一样。

BUILD

建：改定义

加一个 Object Type、一条 Link Type、一个属性。命令是 aidc semantic branch …。分支改定义，不改对象数据。智能体通过提案合并进 main，审核方式由 review 或 yolo 决定。

USE

用：读写数据

读对象、查 SQL、执行 Action。命令是 aidc semantic objects、aidc semantic sql、aidc semantic apply。不需要提案，按调用者的权限走。

分开有两个好处。建的一方不会顺手改数据：给 supplier 加一个属性，不该悄悄动到任何一张采购订单。用的一方不会顺手改定义：忙着下采购订单的智能体，不该把「采购订单」重新定义一遍。示例工厂里，补一个交期承诺的概念属于「建」，事后用它数出晚了几张订单属于「用」。

作者由凭证决定

一次请求是人做的还是智能体做的，不由请求自己说了算。要是作者可以自己声明，智能体一句话就能把自己说成人，「智能体不能直接写 main」也就成了摆设。所以由凭证决定：

  • 用 Agent Key（aidc-sk- 开头）发出的请求，一律是智能体作者。
  • 用人的开发者 Key 发出的请求，如果环境变量 AIDC_AGENT_ID 存在，命令行工具会自动带上 x-aidc-author: agent:procurement-agent 这样的请求头，作者升级成那个智能体。
  • 请求头只能升级、不能降级：不能把智能体说成人。智能体也不能给自己提权。

下面这条命令，作者是智能体，所以直接写 main 会被拒绝：

export AIDC_AGENT_ID=procurement-agent
aidc semantic define ontology-change/
# 退出码 6，409 branch_required：
# 智能体改本体要走分支和提案，不能直接写 main

这个 409 不是故障，是设计：它把智能体推到唯一合法的路上，也就是分支。

按审批策略把关

智能体可以开分支、写定义、开提案。review 只接受本组织 developer 的网页登录审核。yolo 也接受能修改本体的开发者 Key，或主体在本体上是 Editor 或 Owner 的 Agent Key。安全策略改动仍须满足相关 Markings 的人批准。

review 不计作者自己的批准，每项改动都要由人批准。yolo 会计入有修改权限的作者批准，也允许合格贡献者自动批准；检查通过后自动合并。

这条路的第一步，是智能体自己发现该建什么。下一节讲它怎样发现，又怎样确认缺口是真的。

要点

  • 智能体在分支上构建本体。review 由人审核；yolo 允许合格贡献者批准并自动合并。
  • 「建」（改定义，走分支和提案）与「用」（读写数据，走查询与 Action）是两套工具，互不越界。
  • 作者由凭证决定：Agent Key 一律是智能体，开发者 Key 加 AIDC_AGENT_ID 升级为智能体，请求头不能降级。
  • 智能体直接写 main 会得到 409 branch_required，这是设计，不是故障。
  • review 只收本组织 developer 的网页登录。yolo 也收有修改权限的 Key，允许贡献者批准；安全策略改动仍须人批准。

练一练

分清建与用

用你自己的团队做一次盘点。

写下你团队的智能体本周做的六件事，每件标「建」或「用」。哪几件其实两样都沾了？拆成两步。

小测

选一个答案，马上看解析。

Q1采购智能体设了 AIDC_AGENT_ID，直接运行 aidc semantic define 想把 DeliveryPromise 写进 main，会怎样？

Q2下面哪一件事属于「用」，不需要提案？

Q3一位开发者的 Key 在设置了 AIDC_AGENT_ID 的终端里发出请求，作者会记为？

延伸阅读