自进化：智能体提案，人来批准

第 6 课 · 共 6 课 约 6 分钟

在分支上改、自测、开提案；证据齐全；人逐项批准，合并后发一个新版本。

本课目标

读完这一课，你将能够

  • 说出本体为什么要能跟着业务长
  • 走一遍分支、提案、审核、合并
  • 说出提案要带的证据，以及为什么只有人能批准

本体会过时

本体不是建一次就完的。业务一直在变：新接了一个系统，多了一个部门，Loop 里有人问了一个答不出来的问题。本体跟不上，大家就会回到各自的表格里。

在 AIDC，发现缺口、提出修改的是智能体：它每天用本体干活，最先知道哪里不够用。但智能体不能直接改大家正在用的本体（main）。它改的每一处，都要经过人。

智能体来提，人来批准。

分支、提案、审核、合并

  1. 01开分支在副本上改，不影响正在用的本体
  2. 02自测在分支上预览，确认问题能答了
  3. 03开提案按资源列出改动，附上证据
  4. 04人审核逐项批准；破坏性改动要输入名字确认
  5. 05合并落到 main，发一个新的语义版本
export AIDC_AGENT_ID=ops-agent
aidc semantic branch create add-department
aidc semantic branch modify add-department ./ontology --dry-run
aidc semantic branch modify add-department ./ontology
aidc semantic branch propose add-department --title "加部门对象类型" --trigger "问「采购部有几个智能体」答不出"

设了 AIDC_AGENT_ID，命令的作者就记为这个智能体；智能体作者直接改 main 会被拒绝，只能走分支。分支 35 天没有动静会转为不活跃，再过 7 天删除上面的改动。

提案带证据，人来批准

TRIGGER

触发原因

为什么要改：哪个问题答不出、接了哪个新数据源。

CHANGES

改动

按资源列出：新建、修改、删除了什么。

CHECKS

校验

引用是否完整、名字是否冲突、和 main 有没有冲突，加上作者的自测结果。

IMPACT

影响面

最近 30 天谁在用、写入了多少次、哪些应用依赖它。

BREAKING

破坏性

删属性、改类型这类会影响现有应用的改动，单独标出。

审核在网页上进行：每个资源一项，逐项批准或拒绝，任何一项被拒绝，提案就不能合并。破坏性的改动，批准的人要亲手输入资源的名字确认。

批准只接受人的网页登录，不接受任何 Key——不管是智能体的，还是开发者的。智能体可以提、可以改，但不能自己批准自己。

要点

  • 本体要跟着业务长；最先发现缺口的，是每天用它干活的智能体。
  • 智能体不直接改 main：在分支上改、自测、开提案。
  • 提案带五样证据：触发原因、改动、校验、影响面、破坏性。
  • 批准与合并只能由人在网页上做；破坏性改动要输入名字确认。
  • 合并后发一个新的语义版本，大家读的仍是同一份。

练一练

替智能体写一份提案

想一个今天本体答不出来的问题。

说明缺的是对象类型、属性还是关系，打算怎么补。

小测

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

Q1智能体发现本体里缺一个「部门」对象类型，它应该？

Q2一份提案有三个资源，两个批准、一个拒绝，能合并吗？

Q3为什么批准不接受任何 Key？

延伸阅读