智能体在闭环里

智能体放在闭环的哪一处

让模型逻辑接在自动化的效果上是标准做法：它读数据、做判断、产出改动。改动可以直接执行，也可以先暂存成提案，等人审过再执行，审核的人还能看到模型是怎么得出这个提案的。

一个稳妥的分工：条件要确定，判断交给智能体，写入交给 Action。 条件里不放模型，因为同一份数据求两次值，结果应该一样。

AIDC 里有两种「智能体」，别混。工作流里的 model 步骤读前面步骤查到的数据，按 output 声明的字段返回结论，自己不调用工具，也写不了数据。外部智能体（数字员工，或你自己框架里的智能体）能读说明书、调应用的 API，先预演再提交。模型调用按工作流应用计费，每天的 dailyTokens 缺省封顶 1,000,000。

先读说明书，再预演，再提交

外部智能体每次先读说明书：有哪些对象、属性怎么叫、能做哪些 Action；再读触发它的那个对象；然后只用应用登记的 API 做事。为低库存物料建采购草稿，最短的一轮是这样：

aidc semantic describe --markdown                 # read the guide first
aidc semantic object material M-1042 --json       # the object that triggered the run
aidc app apis cell-factory/factory-ops            # which APIs may I call?
aidc app call cell-factory/factory-ops create_purchase_order \
  --param po_no=PO-M-1042-2026-09-29 --param material_code=M-1042 \
  --param supplier_id=S-07 --param qty=400 --preview --json
# show the plan to a person; after a yes, run the same call without --preview

• 写入一律先 --preview：读、算、分析照跑，写入只返回计划；把计划给人看，确认后再正式调用。
• 结论只用 API 返回的内容，不凭记忆补数字。
• 凭证只来自人交给你的 Key；遇到额度或权限错误就停下来告诉人，不要换 Key 重试。

预演之后给人看的，不只是计划，还有依据：读到的对象、算出的缺口、模型写的理由。人批准的是这一整包，而不是一个孤零零的数字。预演也不是免费的：模型分析真的会跑，占用 token 和计算分钟。

模型给理由，公式给边界，人来批准

② 里的智能体只做一件事：从候选供应商里挑一个，给数量，写理由。它挑的东西，有三道关：

1. 公式

   compute 步骤检查供应商在候选名单里、数量是正数，再把数量压在上限内（这里是安全库存的两倍）。检查不过，后面的步骤不执行。

2. Action

   参数有最小值和最大值，提交条件检查供应商评分（示例：不低于 3）。

3. 人

   订单以草稿状态建出。批准用另一个 Action。若要求只由人执行，提交条件必须检查 authorKind 等于 human；只放在人用应用里不够。

前面还有四步：mat 读物料，open 读在途订单，sup 读候选供应商，rule 算缺口和上限。没有缺口时，下面这些步骤一个都不执行：

{ "id": "review", "kind": "model", "title": "Pick supplier and quantity",
  "when": "=steps.rule.needs_order", "model": "deepseek-flash",
  "system": "You are a purchasing analyst. Use only the numbers you are given. Pick a supplier from the list and propose a quantity.",
  "prompt": "Material: {{ steps.mat.row }}\nOpen orders: {{ steps.open.rows }}\nSuppliers: {{ steps.sup.rows }}\nGap: {{ steps.rule.gap }}\nLimit: {{ steps.rule.cap }}",
  "output": { "supplier_id": "text", "qty": "number", "reason": "text" } },
{ "id": "bound", "kind": "compute", "title": "Check and clip",
  "fields": {
    "ok": "=steps.rule.needs_order && (steps.review.qty ?? 0) > 0 && contains(pluck(steps.sup.rows, 'supplierId'), steps.review.supplier_id)",
    "qty": "=min(round(steps.review.qty ?? 0), steps.rule.cap)"
  } },
{ "id": "draft", "kind": "use", "title": "Create the draft order",
  "when": "=steps.bound.ok", "use": "factory-ops/create_purchase_order",
  "with": { "po_no": "=concat('PO-', input.material_code, '-', today())", "material_code": "=input.material_code",
            "supplier_id": "=steps.review.supplier_id", "qty": "=steps.bound.qty" } }

最后一道关在 Action 自己身上，下面是 create-purchase-order 的相关片段：

"parameters": [
  { "name": "supplier", "type": "object", "objectType": "supplier", "required": true },
  { "name": "qty", "type": "integer", "required": true, "min": 1, "max": 100000 }
],
"submissionCriteria": [{
  "condition": { "type": "comparison", "left": { "param": "supplier", "property": "rating" }, "operator": "gte", "right": { "literal": 3 } },
  "failureMessage": "Supplier rating is below 3"
}]

reason 字段不是装饰：它随通知发给采购员，也留在运行记录里，批准的人看它，事后复盘的人也看它。但别把模型自己报的「把握有多大」当成关口，它不是边界。边界要能被复算，也要能被审计。

谁的身份在动手

经应用的 API 调用时，身份是「应用 × 调用人的角色」：读只能读应用登记过的类型，Action 过它自己的角色规则，调用人拿不到应用本来拿不到的东西，留痕记的是调用人。所以让智能体改数据的稳妥路径，是应用的 API，而不是把大权限的 Key 交给它。