用途：指导在工作区中构建多个聚焦单一职责的小应用，通过智能体发现与 A2A 组合协作，而非构建一个超大应用。无头应用可只拥有某个 provider、数据集、工作流或专门动作面，无需完整 UI，由主智能体通过发现与 A2A 组合。
主要能力与规则：每个小应用只承担一项清晰职责，package.json 描述简洁，动作名体现其职责；provider 凭据与上游 API 细节保留在拥有该 provider 或工作流的应用中，其他应用应委托而非复制集成代码；仅在用户需查看状态时提供极简状态/配置界面，纯无头应用亦可；若两个工作流只共享辅助函数，把辅助函数放入 packages/shared，工作流动作仍分属不同应用。
发现与调用：主智能体应先发现可用同级应用。运行时智能体收到由 discoverAgents() 构建的 <available-apps> 块，工作区同级由 discoverWorkspaceAgents() 分层加入，每应用一行，仅表明存在。用内置 describe-workspace-apps 工具获取实际能力，它读取各对等方实时的 /.well-known/agent-card.json，返回用途及可选稳定机器契约，传 app: "<id>" 获取单个对等方完整描述。不要手工维护各应用功能的 markdown 或代码清单。UI 外壳、无头面与脚本可通过 GET /_agent-native/agents?selfAppId=<app-id> 读取同一注册表。代码或 CLI 调用方应使用基于消息的一等 A2A 调用路径（invokeAgent() / agent-native invoke）。智能体循环中用 call-agent 并传同级应用 id；不要用 call-agent 调用当前应用，应使用本地动作。默认发送自然语言目标，让同级应用应用其自身指令、技能、schema、数据字典、凭据与工具；invokeAgentAction() 或 call-agent 带 action + input 仅用于输入已知的显式稳定语义读取契约。发送窄提示，保留返回的 id 与 URL 原样。
产物交接：小应用应交接紧凑产物而非大段转录或 provider 转储，产物含 artifactType、artifactId、createdAt、source、summary、items/records、links。下游应用接收产物 id、URL 与窄后续问题，需要更多细节时回调产物所属应用。
Provider API：provider 专属动作是捷径而非限制，可用 provider-api-catalog、provider-api-docs、provider-api-request 调用真实端点；宽连接、搜索或缺失断言用 stageAs 暂存有界语料，再用 query-staged-dataset 或代码归约。组合时让拥有 provider 的小应用执行这些调用。
示例：销售情报工作区拆为 hubspot-pipeline（CRM 交易等）、gong-evidence（通话与转录证据）、knowledge-base（内部文档与规则）、deal-brief（编排与最终简报），后者通过消息式 invokeAgent() 或 call-agent 调用前三者。
限制与禁止：不要克隆 Mail、Calendar、Analytics、Brain、Assets 等一方应用以复用数据，应委托或链接；不要把多 provider 工作流藏进巨型“杂项工具”应用；不要在 provider-api-request 可安全表达时添加一次性端点；不要创建仅重新导出其他应用动作或 A2A 结果的包装路由。相关技能：a2a-protocol、actions、external-agents、storing-data。