build-agent-broker-project

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

⚠️ HARD OUTPUT CONTRACT — applies to EVERY assistant turn in this skill

⚠️ 硬性输出契约——适用于此 skill 中的每一次 assistant 轮次

You MUST output ≤ 4 lines of user-facing text per turn, unless you are emitting a numbered list of confirmed items (asset list, validation findings, asset → node assignments) — in which case the list itself is the output and gets no preamble.

FORBIDDEN openings. Never start a turn with any of these phrases or their synonyms. If you catch yourself typing one, delete it:

"I'll now..." / "Now I'll..." / "Next, I'll..." / "Let me..."
"First, ..." / "To start, ..." / "Before I do..."
"Based on..." / "Given that..." / "Since..."
"Great!" / "Perfect!" / "Got it!" / "Understood!" / "Sure!"
"I'm going to..." / "I plan to..." / "My approach is..."
"Let me think about..." / "Let me analyze..." / "Let me check..."
"Here's what I'm doing..." / "Here's my plan..." / "Here's a summary..."
"Moving on to..." / "Now that we've..." / "Now we'll..."
Any sentence describing what you are about to do. Just do it.

FORBIDDEN content. Never include in a turn:

Recap of what the user just said. They remember.
Pre-explanation of what comes after this turn. Wait until you get there.
Restating the goal of the current phase. The phase headings handle that.
Step-by-step narration of how you're reasoning. The user sees only the conclusion.
Phase numbers or step numbers in the prose ("Step 4 says..." / "In Phase 2..."). The model uses these to navigate; the user doesn't see them.

REQUIRED shape of a normal turn:

<one action OR one question OR one bulleted list>
<optional: one short follow-up sentence, only if strictly needed>
<stop>

End-of-phase confirmation shape:

<bulleted list of what was captured, ≤ 6 bullets>
Anything missing?

Validation-result shape:

✅ PASS    (or)    ❌ FAIL — <N> issue(s)
- <issue 1>
- <issue 2>

If a phase needs multiple actions, do them in tool calls without narrating between them. Only emit user-facing text at decision/confirmation points.

每轮最多只能输出 ≤ 4 行面向用户的文本，除非输出的是已确认项目的编号列表（asset 列表、验证发现、asset → 节点分配）——此时列表本身就是输出，不加前言。

禁止的开场。 绝不要以以下任何短语或其同义表达开始。如果发现自己正在输入其中之一，请删除：

"I'll now..." / "Now I'll..." / "Next, I'll..." / "Let me..."
"First, ..." / "To start, ..." / "Before I do..."
"Based on..." / "Given that..." / "Since..."
"Great!" / "Perfect!" / "Got it!" / "Understood!" / "Sure!"
"I'm going to..." / "I plan to..." / "My approach is..."
"Let me think about..." / "Let me analyze..." / "Let me check..."
"Here's what I'm doing..." / "Here's my plan..." / "Here's a summary..."
"Moving on to..." / "Now that we've..." / "Now we'll..."
任何描述你接下来要做什么的句子。直接执行。

禁止的内容。 绝不要在一轮中包含：

复述用户刚才说过的话。他们记得。
预先解释这一轮之后会发生什么。等实际到达那里再说。
重述当前阶段的目标。阶段标题已经说明。
逐步叙述你的推理过程。用户只会看到结论。
在正文中使用阶段编号或步骤编号（“第 4 步规定……”“在阶段 2 中……”）。模型用它们导航，用户看不到。

普通轮次的必需结构：

<one action OR one question OR one bulleted list>
<optional: one short follow-up sentence, only if strictly needed>
<stop>

阶段结束时的确认结构：

<bulleted list of what was captured, ≤ 6 bullets>
Anything missing?

验证结果结构：

✅ PASS    (or)    ❌ FAIL — <N> issue(s)
- <issue 1>
- <issue 2>

如果一个阶段需要执行多个操作，请在工具调用中完成，不要在操作之间 narrate。仅在决策或确认节点输出面向用户的文本。

MuleSoft Agent Broker Builder

Turns a natural-language description of a multi-agent workflow into a complete, validated, deployable Agent Network V2 (GA, A2A v1.0) project. Runs a 6-phase guided experience and adds publish + deploy.

The skill is CLI-first end-to-end. Validate/publish/deploy use the Anypoint CLI Agent Fabric plugin (

mulesoft-anypoint-cli-agent-fabric-plugin

). Exchange asset search uses Anypoint CLI v4 (

anypoint-cli-v4 exchange asset list

). Both are portable across Claude Code, Cursor, Codex, and Vibes, and match the CI/CD path. MCP tools (

mcp__mulesoft__*

) work as a fallback when present, but no MCP dependency is required.

将自然语言描述的多 Agent workflow 转换为完整、经过验证且可部署的 Agent Network V2（GA、A2A v1.0）项目。采用六阶段引导式体验，并增加发布与部署能力。

此 skill 以 CLI 优先的方式实现端到端操作。 验证、发布和部署使用 Anypoint CLI Agent Fabric plugin（

mulesoft-anypoint-cli-agent-fabric-plugin

）。Exchange asset 搜索使用 Anypoint CLI v4（

anypoint-cli-v4 exchange asset list

）。两者均可跨 Claude Code、Cursor、Codex 和 Vibes 使用，并与 CI/CD 路径保持一致。存在时，MCP 工具（

mcp__mulesoft__*

）可用作 fallback，但并非必须依赖 MCP。

When to use

何时使用

Use for: building a new Agent Broker; adding/swapping nodes, agents, MCP tools, or LLMs; tuning instructions; changing routing; running validate/publish/deploy.
Don't use for: V1→V2 conversions (use
```
translate-agent-broker-old-to-new-project
```
); standalone Mule apps, DataWeave, or APIs.

If the YAML has

schemaVersion: 1.0.0

, this is V1 — stop and route to the converter. The V2 marker is

agentNetwork: 2.0.0

(unquoted, top of file).

用于：构建新的 Agent Broker；添加或替换节点、Agent、MCP 工具或 LLM；调整 instructions；修改路由；执行验证、发布或部署。
不用于：V1→V2 转换（使用
```
translate-agent-broker-old-to-new-project
```
）；独立的 Mule 应用、DataWeave 或 API。

如果 YAML 中包含

schemaVersion: 1.0.0

，则它是 V1——停止操作并转至 converter。V2 标记是

agentNetwork: 2.0.0

（未加引号，位于文件顶部）。

References (read on demand)

参考资料（按需读取）

references/canonical-example.md
— A complete, working Agent Network V2 (GA, A2A v1.0) project. The structural template — when in doubt, copy it.
references/gotchas.md
— GA syntax rules, compile-error rules, RULE-ASSET-MODE (inline vs Exchange), subagent-vs-orchestrator decision, auth casing, CLI + MCP tooling integration, graceful degradation.

The MuleSoft Agent Network GA docs (Anypoint Code Builder section) are the authoritative reference. The references above cover the gotchas and worked example.

references/canonical-example.md
——完整且可运行的 Agent Network V2（GA、A2A v1.0）项目。这是结构模板——如有疑问，请直接采用。
references/gotchas.md
——GA 语法规则、编译错误规则、RULE-ASSET-MODE（Inline 与 Exchange）、subagent 与 orchestrator 的选择、auth 大小写、CLI 与 MCP 工具集成，以及优雅降级。

MuleSoft Agent Network GA 文档（Anypoint Code Builder 部分）是权威参考来源。上述参考资料涵盖常见陷阱和完整示例。

Node-type terminology (phase language ↔ schema keyword)

节点类型术语（阶段语言 ↔ schema 关键字）

The 6 phases below use user-facing names for node types. The actual

.agent

file uses schema keywords. When talking to the user, use the phase name; when writing the file, use the keyword.

Phase language	`.agent` keyword	What it is
Reasoning node	`subagent`	LLM-with-tools. Accepts actions; has built-in HITL. The default LLM-powered node type.
Orchestrator node	`orchestrator`	LLM-with-tools, specialized for coordinating multiple actions toward a compound goal. Use only when a node has ≥2 actions AND they jointly serve one outcome.
Generate node	`generator`	LLM without tools. For one-shot generation/summarization/classification with structured output.
(no LLM, deterministic)	`router`	Branching based on a known value. Conditions, not prompts.
(no LLM, side-effect)	`executor`	Runs one tool with known args, sets a variable.
(terminal)	`echo`	Sends the final A2A response to the client.

以下六个阶段使用面向用户的节点类型名称。实际

.agent

文件使用 schema 关键字。与用户沟通时使用阶段名称；写入文件时使用关键字。

阶段语言	`.agent` 关键字	含义
Reasoning node	`subagent`	带工具的 LLM。接受 actions；内置 HITL。默认的 LLM 驱动节点类型。
Orchestrator node	`orchestrator`	带工具的 LLM，专门针对围绕复合目标协调多个 actions。仅当节点包含 ≥2 个 actions，且这些 actions 共同服务于一个结果时使用。
Generate node	`generator`	不带工具的 LLM。用于一次性生成、摘要或分类，并输出结构化结果。
（无 LLM，确定性）	`router`	根据已知值进行分支。依据条件，而非 prompt。
（无 LLM，产生副作用）	`executor`	使用已知参数运行一个工具，并设置变量。
（终端）	`echo`	将最终 A2A response 发送给客户端。

Tooling integration (CLI-first, MCP-fallback)

工具集成（CLI 优先，MCP fallback）

The skill prefers the Anypoint CLI Agent Fabric plugin (

mulesoft-anypoint-cli-agent-fabric-plugin

) for validate/publish/deploy and Anypoint CLI v4 (

anypoint-cli-v4

) for Exchange search. The MuleSoft MCP server (

mcp__mulesoft__*

) is the fallback.

Try CLI first. If the CLI fails, fall back to MCP immediately — do NOT ask the user, do NOT retry the CLI, do NOT stop the phase.

A CLI attempt counts as failed when ANY of these happen:

```
command -v
```
returns nothing (binary not installed).
The command exits non-zero for a reason OTHER than the user's own input (e.g.,
```
ENOENT
```
, plugin not installed, auth env vars unset, network error, npm install needed, "command not found",
```
EACCES
```
).
The command hangs past a reasonable timeout (~60s for search, ~5min for build/publish/deploy).
The command returns success but the output is empty / malformed when the schema requires content (e.g., zero assets returned where the user explicitly named one).

A CLI attempt does NOT count as failed when:

The user's input was bad (invalid project name, missing required field) — surface the error to the user, don't fall back.
The validation/build legitimately found schema errors — report them; that's the CLI doing its job.

Fallback procedure (apply silently, in this order):

Catch CLI failure. Note the failure reason in one short internal line — do NOT narrate it to the user unless they ask.
Check if the equivalent
```
mcp__mulesoft__*
```
tool is registered in the session. If yes, call it with the equivalent inputs.
If MCP also fails or isn't present, fall back to the no-tool path (doc link / structural checklist / user prompt) per
```
references/gotchas.md
```
§ "Graceful degradation".
Tell the user only the outcome ("found 3 LLM assets" / "validated — 2 issues" / "couldn't reach Exchange — give me the assetId manually?"), not the tool-by-tool path you took to get there.

If a CLI command needs more info before running (unknown flag, unfamiliar subcommand, ambiguous syntax error): try

<command> --help

first, then a public-web search if

--help

doesn't resolve it. Only after both come up empty should you ask the user. This applies to the CLI plugin AND

anypoint-cli-v4

. Do NOT narrate the lookup; just run the command with the corrected syntax.

See

references/gotchas.md

§ "Tooling integration" for the full capability matrix, CLI command syntax, env-var auth (

ANYPOINT_CLIENT_ID/SECRET/ORG/ENV

), and the per-step CLI ↔ MCP mapping.

此 skill 优先使用 Anypoint CLI Agent Fabric plugin（

mulesoft-anypoint-cli-agent-fabric-plugin

）进行验证、发布和部署，并使用 Anypoint CLI v4（

anypoint-cli-v4

）搜索 Exchange。MuleSoft MCP server（

mcp__mulesoft__*

）作为 fallback。

优先尝试 CLI。如果 CLI 失败，立即回退到 MCP——不要询问用户，不要重试 CLI，也不要中止当前阶段。

出现以下任一情况时，CLI 尝试视为失败：

```
command -v
```
没有任何输出（二进制文件未安装）。
命令因用户输入以外的原因以非零状态退出（例如
```
ENOENT
```
、plugin 未安装、auth 环境变量未设置、网络错误、需要执行 npm install、“command not found”或
```
EACCES
```
）。
命令超过合理的 timeout 仍未返回（搜索约 60 秒；build、publish 或 deploy 约 5 分钟）。
命令返回成功，但 schema 要求包含内容时，输出为空或格式错误（例如用户明确指定某个 asset，却返回零个 asset）。

以下情况不视为 CLI 尝试失败：

用户输入有误（项目名无效、缺少必填字段）——向用户说明错误，不要回退。
validation/build 合法地发现 schema 错误——报告这些错误；这是 CLI 正常工作。

静默按以下顺序执行 fallback：

捕获 CLI 失败。用一行简短内容记录失败原因——除非用户询问，否则不要 narrate。
检查当前会话是否注册了等效的
```
mcp__mulesoft__*
```
工具。如果已注册，使用等效输入调用它。
如果 MCP 同样失败或不存在，则按照
```
references/gotchas.md
```
中“Graceful degradation”一节回退到无工具路径（文档链接／结构检查清单／用户提示）。
仅向用户说明结果（“找到 3 个 LLM asset”“验证完成——有 2 个问题”“无法访问 Exchange——请手动提供 assetId？”），不要说明所采用的工具路径。

如果运行 CLI 命令前需要了解更多信息（未知 flag、不熟悉的 subcommand 或不明确的语法错误）：先尝试

<command> --help

，如果

--help

无法解决，再进行公开网络搜索。只有两者都没有结果时才能询问用户。这同时适用于 CLI plugin 和

anypoint-cli-v4

。不要 narrate 查找过程；使用修正后的语法直接运行命令。

有关完整能力矩阵、CLI 命令语法、env-var auth（

ANYPOINT_CLIENT_ID/SECRET/ORG/ENV

）以及每个步骤的 CLI ↔ MCP 映射，请参阅

references/gotchas.md

中“Tooling integration”一节。

Workflow A — Build a new project (Phases 1–6 + Publish/Deploy)

Workflow A——构建新项目（阶段 1–6 + Publish/Deploy）

The 6 phases below structure the build experience. Each phase ends with a stop point — wait for the user. Apply each user response immediately (no batch-then-update).

以下六个阶段用于组织构建体验。每个阶段都以停止点结束——等待用户。立即应用每项用户回复（不要先批量收集再统一更新）。

Step 1: Pre-flight + scaffold

第 1 步：预检 + 搭建脚手架

Detect existing project. If working folder has
```
agent-network.yaml
```
+
```
exchange.json
```
+
```
brokers/
```
, ask: "Edit this one, or scaffold new in a sibling folder?" Default edit (Workflow B).
Detect schema version.
```
schemaVersion: 1.0.0
```
→ route to converter.
Confirm intent in one sentence: "You want me to build a new Agent Broker that does X. Sound right?"
Collect scaffold inputs (ask before invoking CLI):
- Project name (kebab-case, e.g.
```
it-help-investigation
```
  ) — also becomes the default
```
assetId
```
  .
- Output directory (default: current working dir).
- Asset version (default
```
0.0.0
```
  while in development; user can bump on first publish).
Scaffold via CLI. Run the create command from the parent directory:
```
anypoint-cli-agent-fabric-plugin agent-network project create \
  --name <project-name> \
  --output-dir <parent-dir> \
  --create-dir
```
This produces
```
<project-name>/agent-network.yaml
```
+
```
exchange.json
```
+
```
brokers/
```
with the correct
```
groupId
```
/
```
organizationId
```
(pulled from
```
ANYPOINT_ORG
```
) and starter template. Skill then edits the generated files in place.
- If CLI is unavailable AND
```
mcp__mulesoft__create_agent_network_project
```
  is present, call the MCP tool with the same inputs.
- If neither is available, fall back to writing the canonical scaffold structure directly (
```
agent-network.yaml
```
  with
```
agentNetwork: 2.0.0
```
  ,
```
exchange.json
```
  with
```
"classifier": "agentic-network"
```
  , empty
```
brokers/
```
  ) and tell the user the
```
groupId
```
  /
```
organizationId
```
  placeholder needs to be filled in before publish.
Capture network
info
for
```
agent-network.yaml
```
: ask for
```
info.label
```
(required) and
```
info.description
```
(optional). Default
```
info.version
```
to
```
1.0.0
```
unless user provides one. Apply to the scaffold immediately.

检测现有项目。 如果工作目录中已有
```
agent-network.yaml
```
+
```
exchange.json
```
+
```
brokers/
```
，询问：“编辑这个项目，还是在同级目录中新建脚手架？”默认选择编辑（Workflow B）。
检测 schema 版本。
```
schemaVersion: 1.0.0
```
→ 转至 converter。
用一句话确认意图：“你希望我构建一个执行 X 的新 Agent Broker，对吗？”
收集脚手架输入（调用 CLI 前询问）：
- 项目名称（kebab-case，例如
```
it-help-investigation
```
  ）——同时作为默认
```
assetId
```
  。
- 输出目录（默认：当前工作目录）。
- Asset 版本（开发期间默认
```
0.0.0
```
  ；用户可以在首次发布时提升版本）。
通过 CLI 搭建脚手架。 从父目录运行 create 命令：
```
anypoint-cli-agent-fabric-plugin agent-network project create \
  --name <project-name> \
  --output-dir <parent-dir> \
  --create-dir
```
此命令会生成
```
<project-name>/agent-network.yaml
```
+
```
exchange.json
```
+
```
brokers/
```
，并使用正确的
```
groupId
```
/
```
organizationId
```
（从
```
ANYPOINT_ORG
```
拉取）及起始模板。随后由 skill 原地编辑生成的文件。
- 如果 CLI 不可用，但存在
```
mcp__mulesoft__create_agent_network_project
```
  ，则使用相同输入调用 MCP 工具。
- 如果两者都不可用，则直接编写 canonical 脚手架结构（
```
agent-network.yaml
```
  包含
```
agentNetwork: 2.0.0
```
  ，
```
exchange.json
```
  包含
```
"classifier": "agentic-network"
```
  ，
```
brokers/
```
  为空），并告知用户：发布前需要填写
```
groupId
```
  /
```
organizationId
```
  占位符。
**为
```
agent-network.yaml
```
收集 network
```
info
```
：**询问
```
info.label
```
（必填）和
```
info.description
```
（可选）。除非用户提供其他版本，否则将
```
info.version
```
默认为
```
1.0.0
```
。立即应用到脚手架。

Step 2: Functional Requirements (Phase 1)

第 2 步：功能需求（阶段 1）

Goal: Get the user to define functional requirements clearly. Refuse vague answers — keep prompting until each item is concrete. The user does not need to use graph terminology; natural-language steps are fine.

Capture, in order:

Trigger — what event starts the flow? (Almost always A2A
```
message/send
```
. Confirm.)
Workflow steps & branching logic — "If X happens, then strictly do Y." Walk through each step.
Hard constraints — what is absolutely restricted? These become router conditions, not prompt sentences.
Determinism vs. open-endedness — per step: 100% predictable outcome (graph branching) or LLM reasoning/judgment (LLM-powered node)?

If the user gives a vague answer twice on the same item, accept a placeholder, flag it, and move on.

End the phase with one confirmation: "Here's what I captured: [bulleted summary]. Anything missing?" Stop.

**目标：**让用户清晰地定义功能需求。拒绝含糊回答——持续追问，直到每个项目都足够具体。用户不需要使用 graph 术语；自然语言步骤即可。

按以下顺序收集：

Trigger——什么事件会启动流程？几乎总是 A2A
```
message/send
```
。需要确认。
Workflow 步骤与分支逻辑——“如果发生 X，则严格执行 Y。”逐步确认每个步骤。
硬性约束——哪些行为绝对禁止？这些约束将成为 router conditions，而不是 prompt 文本。
确定性与开放性——针对每个步骤确认：结果是否 100% 可预测（graph 分支），还是需要 LLM 推理或判断（LLM 驱动节点）？

如果用户对同一项目连续两次给出含糊回答，则接受一个占位符，标记后继续。

阶段结束时只进行一次确认：“我捕获到的内容如下：[要点摘要]。还缺少什么吗？”然后停止。

Step 3: Initial Asset Registration (Phase 2)

第 3 步：初始 Asset 注册（阶段 2）

Goal: Find the right assets in Exchange and register them in the YAML.

Asset types: LLMs (always ≥1), MCP tools, A2A agents.

Asset search order — for each capability identified in Phase 1:

Private Exchange first. If

anypoint-cli-v4

is installed:

anypoint-cli-v4 exchange asset list --search "<keywords>" --organization <orgId>

. Else if MCP

search_asset

is available: call with

assetFilters: ["llm"]

["mcp"]

["agent"]

exchangeScope: "Private"

Public Exchange if no Private match. Drop
```
--organization
```
/ set
```
exchangeScope: "Public"
```
.
Placeholder if neither has it. Register as Inline with
```
${var}
```
-style URL/auth placeholders the user can fill in later.

LLM selection is different. Don't auto-pick. List the LLM options found in Exchange (e.g.,

claude

openai

gemini

) and ask: "Pick one or more, or create a new one." Stop.

Review with the user before writing: "Selected: [list]. Confirm?" Stop.

Register every confirmed asset in

agent-network.yaml

exchange.json

. Each asset is in one of two modes — see

references/gotchas.md

§ "RULE-ASSET-MODE":

Inline (asset NOT in Exchange): registry entry +
```
context.connections
```
with
```
ref.name
```
.

Exchange (asset already published):

exchange.json.dependencies

context.connections

with

ref.name

AND

ref.namespace

. No registry entry.

Auth always lives on

context.connections.<id>.authentication

. Parameterize URLs/secrets via

${<name>.url}

${<name>.apiKey}

. Add corresponding

exchange.json.metadata.variables

. Mark secrets

"secret": true

Per-type schema notes:

LLM — Inline:

info.label

metadata.platform: Gemini | OpenAI | AzureOpenai

. Connection:

kind: llm

url

authentication

MCP — Inline:
```
info.label
```
,
```
metadata.transport.kind
```
(
```
streamableHttp
```
|
```
sse
```
|
```
stdio
```
). After registering, ask the user what
tool_name
to call (required for the action). Ask if they know the input parameters. If yes, declare in action
```
inputs:
```
. If no, omit
```
inputs:
```
— runtime auto-discovers. Never fabricate tool names or input schemas.
A2A — Inline:
```
info.label
```
+ interfaces branch. Use
```
a2a
```
for current A2A v1.0 agents,
```
a2a_v03
```
for legacy A2A v0.3 (Agent Broker stays backward-compatible). Card under
```
metadata.interfaces.<branch>.card
```
includes
```
name
```
,
```
description
```
,
```
url
```
,
```
protocolVersion
```
,
```
version
```
,
```
capabilities
```
,
```
defaultInputModes
```
,
```
defaultOutputModes
```
,
```
skills
```
. See
```
references/gotchas.md
```
§ "Registry agents" for the per-branch shape.

**目标：**在 Exchange 中查找正确的 asset，并将其注册到 YAML。

Asset 类型：LLM（始终至少 1 个）、MCP 工具、A2A Agent。

Asset 搜索顺序——针对阶段 1 中识别出的每项能力：

优先搜索 Private Exchange。 如果安装了

anypoint-cli-v4

：

anypoint-cli-v4 exchange asset list --search "<keywords>" --organization <orgId>

。否则，如果 MCP

search_asset

可用：使用

assetFilters: ["llm"]

／

["mcp"]

／

["agent"]

exchangeScope: "Private"

调用。

如果 Private Exchange 没有匹配项，则搜索 Public Exchange。移除
```
--organization
```
，或设置
```
exchangeScope: "Public"
```
。
如果两者都没有，则注册为 Placeholder。以 Inline 模式注册，使用
```
${var}
```
风格的 URL/auth 占位符，供用户稍后填写。

LLM 的选择方式不同。 不要自动选择。列出在 Exchange 中找到的 LLM 选项（例如

claude

、

openai

、

gemini

），并询问：“选择一个或多个，还是创建一个新的？”然后停止。

写入前与用户确认：“已选择：[列表]。确认吗？”然后停止。

将每个已确认 asset 注册到

agent-network.yaml

exchange.json

。每个 asset 分为两种模式——参见

references/gotchas.md

中“RULE-ASSET-MODE”：

Inline（asset 不在 Exchange 中）：registry 条目 +
```
context.connections
```
，其中包含
```
ref.name
```
。
Exchange（asset 已发布）：
```
exchange.json.dependencies
```
+
```
context.connections
```
，其中包含
```
ref.name
```
和
```
ref.namespace
```
。不创建 registry 条目。

Auth 始终位于

context.connections.<id>.authentication

。通过

${<name>.url}

／

${<name>.apiKey}

参数化 URL 和 secret。添加对应的

exchange.json.metadata.variables

。将 secret 标记为

"secret": true

。

各类型的 schema 注意事项：

LLM——Inline：

info.label

、

metadata.platform: Gemini | OpenAI | AzureOpenai

。Connection：

kind: llm

url

authentication

。

MCP——Inline：
```
info.label
```
、
```
metadata.transport.kind
```
（
```
streamableHttp
```
|
```
sse
```
|
```
stdio
```
）。注册后，询问用户要调用哪个
```
tool_name
```
（action 必填）。询问用户是否知道输入参数。如果知道，在 action
```
inputs:
```
中声明。如果不知道，省略
```
inputs:
```
——runtime 会自动发现。绝不编造 tool name 或 input schema。
A2A——Inline：
```
info.label
```
+ interfaces 分支。当前 A2A v1.0 Agent 使用
```
a2a
```
，旧版 A2A v0.3 使用
```
a2a_v03
```
（Agent Broker 仍向后兼容）。
```
metadata.interfaces.<branch>.card
```
下的 card 包含
```
name
```
、
```
description
```
、
```
url
```
、
```
protocolVersion
```
、
```
version
```
、
```
capabilities
```
、
```
defaultInputModes
```
、
```
defaultOutputModes
```
、
```
skills
```
。各分支的具体结构参见
```
references/gotchas.md
```
中“Registry agents”。

Step 4: Technical Graph Definition (Phase 3 — Agent Script)

第 4 步：技术 Graph 定义（阶段 3——Agent Script）

Goal: Translate the functional requirements into the

.agent

graph. Brief drafts of

system.instructions

and per-node instructions only — Phase 5 refines prose.

Guiding principle: Graph = pre-defined rules. LLM node = reasoning. Use the graph for anything that can be definitively hard-coded. Use an LLM-powered node (reasoning/orchestrator/generate) only for tasks that genuinely need reasoning. The graph acts as the spine that enforces high-level stages (e.g. Research → Draft → Review); within each stage, the LLM-powered node has autonomy.

Write the first version of the graph:

Configuration. Pick
```
agent_name
```
from the user's requirements (kebab-case; also the
```
.agent
```
filename stem and broker id, e.g.
```
it-help-investigation
```
).
Trigger (entrypoint). Each broker has exactly one trigger per declared interface.
```
kind: "a2a"
```
,
```
target: "brokers://<broker-id>/a2a"
```
,
```
on_message:
```
is a fixed
```
transition to
```
. Conditionals in the trigger are a compile error — use a router downstream.
LLM-powered nodes (pick the right type per stage):
- Reasoning node (
```
subagent
```
  keyword) — LLM-with-tools. Default LLM-powered type. Has built-in HITL.
- Orchestrator node (
```
orchestrator
```
  keyword) — LLM-with-tools, specialized for coordinating multiple actions toward a compound goal.
- Generate node (
```
generator
```
  keyword) — LLM-without-tools. One-shot generation, summarization, or classification with structured output.
Data structure (variables). Declare any state shared across nodes.
Deterministic connections. Every non-terminal node has a single
```
on_exit: -> transition to @<nodeType>.<nodeId>
```
. Every reachable path terminates at
```
echo
```
.
Conditionals live in router nodes. Routers declare
```
routes:
```
+
```
otherwise:
```
and have no
```
on_exit
```
(
```
transition to
```
inside router
```
on_exit
```
is a compile error). Hard constraints from Phase 1 → router conditions, not prompts. Prompts can be ignored; router conditions cannot.
First node after trigger should NOT be a pass-through executor that copies
```
@request.payload.message
```
. Reference
```
@request.payload.message.parts[0].text
```
directly downstream.
Echo terminus. Every reachable path ends in
```
echo
```
with
```
kind: "a2a:status_update_event"
```
(or
```
"a2a:artifact_update_event"
```
for artifacts). See
```
references/gotchas.md
```
§ "Echo node" for the
```
TASK_STATE_*
```
enum and
```
a2a.*
```
helper rules.

Write a first version of

system.instructions

and each LLM-powered node's prompt — keep them brief; Phase 5 refines.

Update the

brokers

entry in

agent-network.yaml

to reference the new

.agent

file. For full compile-error rules see

references/gotchas.md

§ "Compile-error rules". For the structural template see

references/canonical-example.md

**目标：**将功能需求转换为

.agent

graph。

system.instructions

和各节点 instructions 只需简要草稿——阶段 5 会进一步优化。

指导原则：Graph = 预定义规则。LLM 节点 = 推理。 能够明确硬编码的内容都应放在 graph 中。只有真正需要推理的任务，才使用 LLM 驱动节点（Reasoning/Orchestrator/Generate）。Graph 充当“脊柱”，确保高层阶段按顺序执行（例如 Research → Draft → Review）；在每个阶段内部，LLM 驱动节点保有自主性。

编写 graph 的第一版：

配置。 根据用户需求选择
```
agent_name
```
（kebab-case；同时作为
```
.agent
```
文件名主干和 broker id，例如
```
it-help-investigation
```
）。
Trigger（entrypoint）。 每个 broker 针对每个已声明 interface 恰好有一个 trigger。
```
kind: "a2a"
```
、
```
target: "brokers://<broker-id>/a2a"
```
，
```
on_message:
```
是固定的
```
transition to
```
。Trigger 中使用条件会触发编译错误——请在下游使用 router。
LLM 驱动节点（按阶段选择正确类型）：
- Reasoning node（
```
subagent
```
  关键字）——带工具的 LLM。默认 LLM 驱动类型。内置 HITL。
- Orchestrator node（
```
orchestrator
```
  关键字）——带工具的 LLM，专门针对围绕复合目标协调多个 actions。
- Generate node（
```
generator
```
  关键字）——不带工具的 LLM。用于一次性生成、摘要或分类，并输出结构化结果。
数据结构（变量）。 声明节点之间共享的所有状态。
确定性连接。 每个非终端节点都有唯一的
```
on_exit: -> transition to @<nodeType>.<nodeId>
```
。每条可达路径最终都终止于
```
echo
```
。
条件分支位于 router 节点中。Router 声明
```
routes:
```
+
```
otherwise:
```
，且没有
```
on_exit
```
（在 router
```
on_exit
```
中使用
```
transition to
```
会触发编译错误）。阶段 1 中的硬性约束 → router conditions，而不是 prompts。Prompt 可能被忽略；router conditions 不会被忽略。
Trigger 后的第一个节点不应是复制
```
@request.payload.message
```
的直通 executor。应在下游直接引用
```
@request.payload.message.parts[0].text
```
。
Echo 终点。 每条可达路径最终都进入
```
echo
```
，其
```
kind: "a2a:status_update_event"
```
（artifact 则使用
```
"a2a:artifact_update_event"
```
）。有关
```
TASK_STATE_*
```
enum 和
```
a2a.*
```
helper 规则，请参阅
```
references/gotchas.md
```
中“Echo node”。

编写

system.instructions

和每个 LLM 驱动节点 prompt 的第一版——保持简洁；阶段 5 会进一步优化。

更新

agent-network.yaml

中的

brokers

条目，使其引用新的

.agent

文件。完整编译错误规则参见

references/gotchas.md

中“Compile-error rules”。结构模板参见

references/canonical-example.md

。

Step 5: Asset Assignment to Graph (Phase 4)

第 5 步：将 Asset 分配给 Graph（阶段 4）

Goal: Assign assets from the YAML to the correct LLM-powered nodes.

Guiding principles:

Specialize each LLM-powered node in one domain. Lump similar assets into the same node rather than spreading them.
Reasoning vs. Orchestrator — pick by what's connected:
- Only MCP assets on the node → Reasoning node (
```
subagent
```
  ).
- Any A2A assets on the node → Orchestrator node (
```
orchestrator
```
  ).
≤ 4 total assets per LLM-powered node (A2A + MCP combined). More than that → hallucinations. Split the node.
Principle of Least Privilege. One node gets read-only tools; another gets write-access tools. Never combine.
Irreversible mutations (escalate, delete, send-to-customer, etc.) MUST be in
executor
nodes gated by
router
. Never put them on a reasoning/orchestrator node — the LLM could invoke them bypassing the router. Idempotent updates (status updates, ticket updates) MAY live on an orchestrator if part of the compound goal.

Action:

Re-read the graph, the YAML, and the per-node instructions to refresh context.
For each reasoning/orchestrator node, assign assets: "Which YAML asset does this node need?" If none is available, ask the user to create one.
Bind in the
```
.agent
```
file. Each asset gets an
```
actions:
```
entry (A2A:
```
target
```
+
```
kind
```
only, no
```
inputs:
```
; MCP:
```
target
```
,
```
kind
```
,
```
tool_name
```
, optional
```
inputs:
```
). Reference from
```
reasoning.actions
```
(reasoning/orchestrator nodes) or
```
do: run
```
(executor nodes).
Review with the user once all nodes are assigned: "Here are the asset → node assignments: [list]. Confirm?" Stop.
Ask the user to pick the LLM for each LLM-powered node (different nodes can use different LLMs — cheap one for classification, stronger one for orchestration).
Write a one-line human-readable description of what each reasoning/orchestrator node does. Store it on the node.

For full binding rules see

references/gotchas.md

§ "Compile-error rules — action invocation" — A2A bare reference vs
```
with message =
```
in executor; MCP
```
with
```
rules;
```
http_headers
```
implicit.
§ "Stage 4: Bind to nodes" — 4-asset cap, least-privilege, action alias naming.

**目标：**将 YAML 中的 asset 分配给正确的 LLM 驱动节点。

指导原则：

让每个 LLM 驱动节点专注于一个领域。 将相似 asset 集中在同一节点，而不是分散到多个节点。
Reasoning 与 Orchestrator 的选择——根据节点连接的内容决定：
- 节点上只有 MCP asset → Reasoning node（
```
subagent
```
  ）。
- 节点上存在任何 A2A asset → Orchestrator node（
```
orchestrator
```
  ）。
每个 LLM 驱动节点最多分配 4 个 asset（A2A + MCP 合计）。超过会导致 hallucination，应拆分节点。
最小权限原则。 一个节点只配备只读工具，另一个节点配备写权限工具。绝不能混用。
不可逆 mutation（escalate、delete、send-to-customer 等）必须放在由
```
router
```
控制门控的
```
executor
```
节点中。绝不能放在 Reasoning/Orchestrator 节点上——LLM 可能绕过 router 直接调用。幂等更新（status update、ticket update）如果属于复合目标的一部分，可以放在 orchestrator 中。

操作：

重新读取 graph、YAML 和各节点 instructions，以刷新上下文。
为每个 Reasoning/Orchestrator 节点分配 asset：“这个节点需要哪个 YAML asset？”如果没有可用 asset，请用户创建一个。
在
```
.agent
```
文件中完成绑定。每个 asset 都获得一个
```
actions:
```
条目（A2A：仅
```
target
```
+
```
kind
```
，不要
```
inputs:
```
；MCP：
```
target
```
、
```
kind
```
、
```
tool_name
```
、可选的
```
inputs:
```
）。从
```
reasoning.actions
```
（Reasoning/Orchestrator 节点）或
```
do: run
```
（executor 节点）引用。
所有节点分配完成后，与用户进行一次确认：“以下是 asset → 节点分配：[列表]。确认吗？”然后停止。
请用户为每个 LLM 驱动节点选择 LLM——不同节点可以使用不同 LLM，例如分类使用低成本模型，orchestration 使用能力更强的模型。
为每个 Reasoning/Orchestrator 节点编写一行人类可读说明并存储在节点上。

完整绑定规则参见

references/gotchas.md

：

“Compile-error rules — action invocation”——A2A 裸引用与 executor 中
```
with message =
```
的区别；MCP
```
with
```
规则；
```
http_headers
```
隐式行为。
“Stage 4: Bind to nodes”——4-asset 上限、最小权限、action alias 命名。

Step 6: Instruction Refinement (Phase 5)

第 6 步：优化 Instructions（阶段 5）

Goal: Refine and battle-test instructions on every LLM-powered node. One node at a time, never batch.

For each generate/reasoning/orchestrator node:

Name the node, once: "Refining
classifySeverity
." (Don't repeat which node you're on across turns — the user remembers.)
Show V1 of
```
system.instructions
```
(the brief draft from Phase 3).
Ask once: "Overall feedback? Any success criteria or few-shot examples?" Stop.
Write V2 as a numbered routine. Each step → one tool call or one output decision. No "be helpful" / "be professional".
Make outputs concrete. If the node has
```
outputs.properties.severity.enum
```
, the prompt must say "Set severity to high when X, low otherwise" using the enum literals exactly.
Anticipate edge cases. What if a key field is missing? Bake the answer in.
Per-node contradiction test. Does any V2 step get ruled out by deterministic graph logic? Reconcile.
Apply V2 to file immediately. Move to next node.

After every node is refined: run the cross-node contradiction test — does any prompt step conflict with another node's prompt or the graph? Surface conflicts to the user and resolve.

**目标：**优化并全面测试每个 LLM 驱动节点的 instructions。一次处理一个节点，绝不批量处理。

对于每个 Generate/Reasoning/Orchestrator 节点：

只提及一次节点名称：“正在优化
```
classifySeverity
```
。”（不要在多轮中重复当前节点；用户记得。）
展示 V1 的
```
system.instructions
```
（阶段 3 中的简要草稿）。
只询问一次：“整体反馈如何？有没有成功标准或 few-shot 示例？”然后停止。
将 V2 编写为编号流程。每个步骤对应一次 tool call 或一个输出决策。不要使用“要乐于助人”“要专业”等表述。
让输出具体明确。 如果节点包含
```
outputs.properties.severity.enum
```
，prompt 必须使用完全一致的 enum literal，例如“当 X 时将 severity 设置为 high，否则设置为 low”。
预判边缘情况。 如果缺少关键字段会怎样？将对应行为写入 instructions。
执行逐节点矛盾测试。 V2 的任何步骤是否会被确定性 graph 逻辑排除？统一两者。
立即将 V2 写入文件。然后继续下一个节点。

**每个节点优化完成后：**执行跨节点矛盾测试——某个 prompt 步骤是否与另一个节点的 prompt 或 graph 冲突？向用户指出冲突并解决。

Step 7: Final Topology Review (Phase 6)

第 7 步：最终 Topology 审查（阶段 6）

Cleanup, then validate.

Cleanup:

Remove unresolved
```
{{...}}
```
markers, unused
```
exchange.json
```
variables.
Remove unused
```
registry
```
assets (not referenced by
```
context.connections
```
, actions, or LLM blocks).
Remove unused
```
context.connections
```
entries.
Remove orphaned action definitions in
```
.agent
```
file.
Remove empty YAML keys (
```
registry.llms:
```
with no entries → drop the key).

Validate. Run the build command (CLI preferred → MCP fallback → structural checklist below + install hint). Full command syntax in

references/gotchas.md

§ "Step 7 — Validate / build".

Structural checklist:

Every node reachable from trigger? No orphans.
Every reachable path terminates at
```
echo
```
?
Every
```
router
```
has
```
routes
```
(≥1) and
```
otherwise
```
?

Every

subagent

orchestrator

has

reasoning.instructions

AND ≥1 action OR HITL?

Every action referenced in nodes matches an entry in
```
actions:
```
?
Every
```
${...}
```
variable has matching
```
exchange.json.metadata.variables
```
entry?

Every

context.connections.<id>.ref.name

resolves to a registry entry OR

exchange.json.dependencies

All A2A actions in
```
reasoning.actions
```
are bare references (no
```
with message =
```
)?
All MCP
```
with
```
parameters reference declared
```
inputs:
```
fields?
All echo
```
state
```
values in the allowed enum?
Hard constraints enforced via router conditions, not prompts?
Operational caps set:
```
max_number_of_loops
```
lowered from default 25 (e.g., 3 classification, 5–10 orchestration);
```
task_timeout_secs
```
set if calling slow downstream agents?

Fix loop:

Group errors by file. Auto-fix formatting/indentation/missing required keys. For schema-required references missing, ask the user — never auto-insert missing assets. Loop until clean.

When clean: "Project is validated and ready. Want to publish to Exchange and deploy to runtime?"

先清理，再验证。

清理：

移除未处理的
```
{{...}}
```
标记和未使用的
```
exchange.json
```
variables。
移除未使用的
```
registry
```
assets（未被
```
context.connections
```
、actions 或 LLM blocks 引用）。
移除未使用的
```
context.connections
```
条目。
移除
```
.agent
```
文件中孤立的 action 定义。
移除空的 YAML keys（例如没有条目的
```
registry.llms:
```
）。

验证。 运行 build 命令（优先 CLI → MCP fallback → 下方结构检查清单 + 安装提示）。完整命令语法参见

references/gotchas.md

中“Step 7 — Validate / build”。

结构检查清单：

每个节点是否都能从 trigger 到达？不应存在孤立节点。
每条可达路径是否都终止于
```
echo
```
？
每个
```
router
```
是否都包含
```
routes
```
（≥1）和
```
otherwise
```
？
每个
```
subagent
```
/
```
orchestrator
```
是否都有
```
reasoning.instructions
```
，并且包含 ≥1 个 action 或 HITL？
节点中引用的每个 action 是否都匹配
```
actions:
```
中的条目？
每个
```
${...}
```
variable 是否都有对应的
```
exchange.json.metadata.variables
```
条目？

每个

context.connections.<id>.ref.name

是否都能解析到 registry 条目或

exchange.json.dependencies

？

```
reasoning.actions
```
中的所有 A2A action 是否都是裸引用（没有
```
with message =
```
）？
所有 MCP
```
with
```
参数是否都引用已声明的
```
inputs:
```
fields？
所有 echo
```
state
```
值是否都位于允许的 enum 中？
硬性约束是否通过 router conditions 强制执行，而不是 prompts？
是否设置了运行上限：将
```
max_number_of_loops
```
从默认 25 调低（例如分类设为 3，orchestration 设为 5–10）；调用慢速下游 Agent 时是否设置了
```
task_timeout_secs
```
？

修复循环：

按文件对错误分组。自动修复格式、缩进和缺失的必填 keys。对于缺少 schema 要求的引用，询问用户——绝不自动插入缺失的 asset。循环执行，直到项目完全通过检查。

检查通过后：“项目已验证并准备就绪。要发布到 Exchange 并部署到 runtime 吗？”

Step 8: Publish (optional)

第 8 步：发布（可选）

Only if user wants to. Prereqs: authenticated CLI/MCP context;

exchange.json

has

assetVersion

and no empty

default: ""

for

secret: true

variables.

Run the publish command (CLI preferred → MCP fallback → doc link). Surface published asset URLs from the output. Full command syntax is in

references/gotchas.md

§ "Step 8 — Publish".

仅在用户需要时执行。前置条件：已通过 CLI/MCP 完成认证；

exchange.json

包含

assetVersion

，且所有

secret: true

variables 都没有空的

default: ""

。

运行 publish 命令（优先 CLI → MCP fallback → 文档链接）。从输出中提供已发布的 asset URL。完整命令语法参见

references/gotchas.md

中“Step 8 — Publish”。

Step 9: Deploy (optional)

第 9 步：部署（可选）

Only if user wants to. Publish must have happened first.

Ask the user:

environmentName

targetSpace

(private space), and any deployment properties for env-specific secrets (e.g.,

--property openai.apiKey:STAGING_API_KEY

One-time setup per private space: if the target space has no gateways yet, run the gateway setup command first.

Run the deploy command (CLI preferred → MCP fallback → doc link). Surface deployment URL/ID. Full command syntax, gateway defaults, and CI flags are in

references/gotchas.md

§ "Step 9 — Deploy".

仅在用户需要时执行。必须先完成发布。

询问用户：

environmentName

、

targetSpace

（private space），以及用于环境专属 secret 的部署 properties（例如

--property openai.apiKey:STAGING_API_KEY

）。

**每个 private space 的一次性设置：**如果目标 space 尚无 gateway，请先运行 gateway setup 命令。

运行 deploy 命令（优先 CLI → MCP fallback → 文档链接）。提供部署 URL/ID。完整命令语法、gateway 默认值和 CI flags 参见

references/gotchas.md

中“Step 9 — Deploy”。

Workflow B — Edit an existing project

Workflow B——编辑现有项目

Universal edit principles:

Impact analysis first. Identify every downstream node, expression, or connection that depends on the change. Confirm with user.
Minimal disruption. Edit only what's asked. Exception: node-type changes (subagent ↔ orchestrator) when actions are added/removed.
Registry-first. New assets go in
```
agent-network.yaml
```
registry/context (or
```
exchange.json.dependencies
```
) BEFORE being referenced from
```
.agent
```
.
Defer validation while editing. Lint errors mid-edit are expected; validate at the end.

通用编辑原则：

先进行影响分析。 找出所有依赖此次变更的下游节点、表达式或连接。与用户确认。
尽量减少干扰。 仅编辑用户要求的内容。例外：添加或删除 actions 时，需要调整节点类型（subagent ↔ orchestrator）。
Registry 优先。 新 asset 必须先加入
```
agent-network.yaml
```
registry/context（或
```
exchange.json.dependencies
```
），然后才能在
```
.agent
```
中引用。
编辑期间推迟验证。 编辑过程中出现 lint errors 属于正常现象；最后统一验证。

B.1 — Add or swap an asset

B.1——添加或替换 Asset

Decide mode (Inline or Exchange — see
```
gotchas.md
```
).

Inline:

registry.{agents,mcps,llms}

context.connections.<id>

with auth +

exchange.json.metadata.variables

. Exchange:

exchange.json.dependencies

context.connections.<id>

with

ref.name

ref.namespace

Add
```
actions:
```
entry in the
```
.agent
```
file.
Reference from target node's
```
reasoning.actions
```
(subagent/orchestrator) or
```
do: run
```
(executor).
Re-evaluate node type if action count changed. Single action →
```
subagent
```
. Multi-action →
```
orchestrator
```
. Update
```
@<oldType>.<id>
```
references downstream.
Cap check. If a node now exceeds 4 actions, propose splitting.
Update
system.instructions
to explain how to use the new asset.
Run Step 7 (validate).

决定模式（Inline 或 Exchange，参见
```
gotchas.md
```
）。

Inline：

registry.{agents,mcps,llms}

context.connections.<id>

，包含 auth +

exchange.json.metadata.variables

。Exchange：

exchange.json.dependencies

context.connections.<id>

，包含

ref.name

ref.namespace

。

在
```
.agent
```
文件中添加
```
actions:
```
条目。
从目标节点的
```
reasoning.actions
```
（subagent/orchestrator）或
```
do: run
```
（executor）引用。
如果 action 数量发生变化，重新评估节点类型。 单个 action →
```
subagent
```
。多个 action →
```
orchestrator
```
。更新下游的
```
@<oldType>.<id>
```
引用。
检查上限。 如果节点现有 actions 超过 4 个，建议拆分节点。
更新
```
system.instructions
```
，说明如何使用新 asset。
运行第 7 步（验证）。

B.2 — Change graph logic

B.2——修改 Graph 逻辑

Edit

.agent

. After any change, walk trigger → every echo and confirm:

Every router
```
when:
```
references a real, reachable upstream output (not
```
@request.payload
```
directly).
Hard constraints still in router conditions, not prompts.
No node became unreachable or dead-end.
No
```
transition to
```
in a router's
```
on_exit
```
(compile error).

Run Step 7.

编辑

.agent

。每次变更后，从 trigger 遍历到每个 echo，并确认：

每个 router
```
when:
```
都引用真实且可达的上游 output（不能直接引用
```
@request.payload
```
）。
硬性约束仍位于 router conditions 中，而不是 prompts 中。
没有节点变得不可达或形成 dead end。
router 的
```
on_exit
```
中没有
```
transition to
```
（编译错误）。

运行第 7 步。

B.3 — Refine instructions

B.3——优化 Instructions

Edit

.agent

only. Apply Phase 5 contradiction tests. If user pastes a policy doc, transform into numbered routine — don't paste verbatim. Run Step 7.

仅编辑

.agent

。应用阶段 5 的矛盾测试。如果用户提供 policy doc，将其转换为编号流程——不要逐字粘贴。运行第 7 步。

B.4 — Add or change a connection policy

B.4——添加或修改 Connection Policy

Edit

agent-network.yaml

. The GA schema supports policies even though the build flow doesn't surface them.

A policy has two parts:

Definition —
```
context.policies.<policyId>
```
.

Binding — referenced from

context.connections.<connId>.policies.outbound

brokers.<brokerId>.interfaces.a2a.policies.{inbound,outbound}

. Always reference by id.

For Exchange-published policies: add to

exchange.json.dependencies

first, then bind. Run Step 7.

编辑

agent-network.yaml

。即使 build flow 未展示 policies，GA schema 仍支持 policies。

一个 policy 包含两部分：

定义——
```
context.policies.<policyId>
```
。

绑定——通过

context.connections.<connId>.policies.outbound

或

brokers.<brokerId>.interfaces.a2a.policies.{inbound,outbound}

引用。始终通过 id 引用。

对于已发布到 Exchange 的 policy：先将 dependency 添加到

exchange.json.dependencies

，然后再绑定。运行第 7 步。