做自己的领域能力

一个领域能力 = 词（你这一行怎么称呼东西）+ 判据（什么条件下推出什么结论）。装到智能体身上之后，它就按这套规矩办事——能力不是标签，是真的改变判定。

为什么要自己写

通用模型知道"审批"这个词，但不知道你们公司的审批：五万以上要不要两家报价、谁的签字算数、材料缺一件能不能先批。这些规矩写在你们的制度里，不在模型的权重里。

把它们写成一个包装到智能体身上，它就不再靠"我觉得应该"办事——每个结论都落在你写的判据上，而且你能顺着依据链检查它到底按哪条判的。

现成的能力

在控制台的领域能力页选一个智能体，一键装上即可。

自己写一个：完整例子

下面这个包判定"两家不同报价才算可比价"。把它粘到控制台领域能力页的输入框，点校验会当场告诉你哪里要改，通过后一键装到智能体上。

{
  "id": "purchase",
  "title": "采购审批",
  "vocab": [
    { "predicate": "po",         "args": ["id", "amount"] },
    { "predicate": "quote",      "args": ["po", "vendor"] },
    { "predicate": "comparable", "args": ["po"] }
  ],
  "rules": [
    {
      "id": "purchase_comparable",
      "label": "至少两家不同报价才算可比价",
      "when": [
        { "predicate": "po",    "args": { "id": "?p", "amount": "?a" } },
        { "predicate": "quote", "args": { "po": "?p", "vendor": "?v1" } },
        { "predicate": "quote", "args": { "po": "?p", "vendor": "?v2" } },
        { "predicate": "neq",   "args": { "left": "?v1", "right": "?v2" } }
      ],
      "then": [ { "predicate": "comparable", "args": { "po": "?p" } } ]
    }
  ]
}

装上之后，智能体记下这些材料：

po(id=PO-77, amount=52000)
quote(po=PO-77, vendor=A)
quote(po=PO-77, vendor=B)

板自己推出：

comparable(po=PO-77) [derived] <- purchase_comparable, PO1, Q1, Q2

只有一家报价时不会推出来——这正是你要的行为，而且它不依赖谁记得检查。

写包的要点

词要先声明

规则里用到的每个名词都要在 vocab 里出现。同一个词每次用同样的参数名，板才认得出说的是同一件事——quote(po, vendor) 和 quote(order, supplier) 在板看来是两个不同的词。

变量是 ? 开头

变量只出现在规则里（?p、?v1），事实里永远是具体值。同一条规则里同名变量必须匹配同一个值——这就是上例中"同一张采购单的两个报价"的表达方式。

结论里的变量必须被前提绑定

then 用到 ?p，就得有一条正面前提提到 ?p。naf 前提不算绑定（它说的是"这件事不成立"，绑不出值来）。

label 用人话写

它会出现在结论的"依据"里给人看，是可审计性的门面。写「至少两家不同报价才算可比价」，不要写 rule_3。

算数与比较交给板

eq/neq/lt/lte/gt/gte、add/sub/mul/div/min/max 直接写在 when 里，板会精确计算。

{ "predicate": "mul", "args": { "left": "?unit", "right": "?qty", "result": "?total" } },
{ "predicate": "gt",  "args": { "left": "?total", "right": 50000 } }

不要自己算再把结果当材料填进去——那就把"可核对"这件事丢掉了。算术是 exact-or-fail：越界即失败，绝不静默舍入。

缺席用 naf

{ "predicate": "signed", "args": { "request": "?r", "role": "manager" }, "naf": true }

意思是"这件事无法被证明"。用它表达"还没签字"，而不是要求谁去断言"没签字"——没有人去断言缺席，本来就是缺席的常态。

这条写法的效果：缺签字就挂在待签，不会因为无人反对而滑向通过。这是审批类判据最容易写错、也最要紧的地方。

云上现在收哪些字段

包格式的权威标准在核心仓（含完整字段表与 JSON Schema），它描述的是完整格式；而云上宿主点亮的是其中一个子集。下表是云上此刻的实况——每一行都来自在生产上真试过一遍，照它写不会白写。

标着换路径的那行值得留意：判据规则（标准里的 axioms）目前不经包体装载，而是作为包的 rules 由控制台自动上板。你按上面的例子写就已经走在这条路上了。

校验器会拦住什么

控制台的校验按钮不只查 JSON 语法，它把问题一次全说完（不是修一个撞一个）：

• 用了没在 vocab 里声明的词
• 结论里的变量没有任何正面前提绑定它
• then 里用了内建谓词或 naf
• 缺人话 label
• 带了云上还不支持的字段（会点名是哪个字段、去掉即可装）

这些错误板本身也会拒，但报错来得更晚、更难懂。在提交那一刻拦住，是为了让你不必先学会读板的报错才能写包。

工具包（有哪双手）

除了词与判据，包还能声明工具——这一行里有哪几双手、每双手什么治理等级：

• read 只读（查一下）
• write 写（改数据）
• run 执行（跑东西）

工具落到板上是"板证：现场有这几双手"，治理等级决定它需不需要清关才能动。

如实说明当前边界：工具可以定义、可以装上，但"模型跑完工具后把结果过膜回报给板"这一环还没开放（回报要进受信档，才能被判据当证据用）。所以工具目前是声明，闭环待补。写包时可以先声明好，等这一环开放后立即可用。