Agent 系统

AuraBoot 的 Agent 系统将应用元数据转化为安全的 AI 动作。Aura Bot 可以回答问题、检视当前页面上下文、调用已批准的工具,并通过与普通用户相同的 Command Pipeline 执行多步工作。
关键设计选择是 Agent 不绕过平台。它通过 Model、Command、命名查询、Permission、审计日志、审批与 trace 运作。这让 AI 在业务应用中可用,同时避免出现一条不可控的第二自动化路径。
运行时分层
| 层 | 用途 | 运行时产物 |
|---|---|---|
| Aura Bot 面板 | 面向用户的对话与上下文助手 | 流式对话会话 |
| LLM Provider | 模型选择与 API 执行 | 云端配置的 Provider |
| Agent 定义 | 角色、指令、模型、守卫 | Agent 元数据记录 |
| 工具契约 | 工具用途、schema、风险、确认策略 | 原生工具配置 |
| Command Pipeline | 认证、校验、事务、审计、事件 | Command 执行结果 |
| Trace | 调试、成本、span、工具调用 | AI trace 与 span 记录 |
这种分层让用户体验保持对话化,同时让执行足够确定,便于运维团队检视。
Aura Bot 与 Agent 运行时
Aura Bot 是用户界面,Agent 运行时是其背后的执行层。
Aura Bot 负责:
- 从应用外壳打开右侧助手面板
- 收集当前页面上下文、记录上下文、Model 元数据与选中字段
- 从已配置的模型 Provider 流式获取响应
- 提供 explain、summarize、draft 或 query 等快捷操作
Agent 运行时负责:
- 加载 Agent 定义与守卫
- 从元数据派生的契约中选择工具
- 调用 DSL Command、命名查询或已批准的原生工具
- 应用确认与审批规则
- 记录 trace span、工具调用、失败与成本
工具契约
每个 Agent 工具都应具有契约。契约解释该工具做什么、何时应使用、接受什么输入 schema、返回什么输出 schema 以及携带什么风险等级。
AuraBoot 可以从元数据派生大多数契约:
| 来源 | 派生的契约字段 |
|---|---|
| Command 定义 | 用途、副作用、风险等级、输入 schema |
| Model 元数据 | 字段名、数据类型、必填输入 |
| 命名查询 | 只读查询的用途与参数 |
| 能力注册中心 | 版本、归属、可组合性 |
| Agent hint | 人类编写的使用指引 |
契约质量很重要。如果一个工具仅说"update record",模型可能过于频繁选择它;如果它说"当请求人需要修正字段时,将已批准的采购请求回退到草稿",模型就能做出更窄、更安全的决定。
风险与确认
Agent 执行将 Command 风险映射为确认行为。
| 风险 | 示例 | Agent 行为 |
|---|---|---|
| L0(只读) | 查询记录或汇总页面 | 无需确认直接执行 |
| L1(内部写) | 创建一条草稿记录(单对象写入) | 通常直接执行 |
| L2(跨对象) | 变更状态或运行批量级联更新 | 询问一次或要求显式确认 |
| L3(外部副作用) | 调用外部系统或触发对外动作 | 要求确认且通常需要审批 |
| L4(不可逆) | 删除、审批支付、不可逆操作 | 始终确认且通常需要审批 |
同样的权限检查依然适用。如果用户无法手工运行某个 Command,Agent 也不能代用户运行。
多步执行
Agent 可以把工作分解为步骤。一个典型请求"创建一个 campaign,加 3 个 task,并总结后续动作"会被分解为:
- 理解目标 Model 与必填字段
- 通过 create Command 创建 campaign
- 通过 Command 调用创建子 task 记录
- 查询生成的记录
- 返回包含链接的摘要
每次写操作仍然走 Command Pipeline。Agent 收到的是结构化结果,而不是抓取 UI。
协作模式
高级部署可以将 Agent 工作建模为任务。核心模式如下:
| 模式 | 行为 | 用途 |
|---|---|---|
| Delegate | 父任务将一个子任务指派给特定 Agent | 专家评审或计算 |
| Broadcast | 多个 Agent 尝试同一任务,选出最佳结果 | 起草、分类、分析 |
| Pipeline | Agent 步骤顺序运行并前向传递输出 | 多阶段补全或评审 |
OSS 文档应将其视为架构概念,除非部署启用了对应的任务管理界面。
可观测性
Agent 工作必须可调试。AuraBoot 记录模型调用与工具调用的 trace 数据,以便管理员回答:
- 使用了哪个 prompt 与模型?
- 选择了哪个工具,为什么?
- 传给工具的参数是什么?
- 校验、权限或下游执行是否失败?
- 模型调用与工具调用各耗时多久?
- Token 或 Provider 成本是多少?
trace 数据也有助于改进工具描述。如果某个工具频繁被错用,修复往往是更好的契约,而不是更大的模型。
Plugin 作者职责
当 Plugin 作者希望其能力与 Aura Bot 良好协作时,应当:
- 定义精确的 Model 名、字段标签与描述
- 让 Command 输入 schema 保持严格且完整
- 在 Command 上设置贴近实际的风险等级
- 为含糊操作添加
agent_hint或等效指引 - 读多型分析优先使用命名查询
- 避免在没有清晰前置条件的情况下暴露高风险工具
边界
Agent 很强大,但不是平台规则的替代品。不要用 Agent 绕过缺失的 Command、弱权限或不完整的校验。如果某项操作对业务重要,先把它建模为 Command,再让 Agent 调用该 Command。
下一步
- Agent Workflow — 配置 Provider、工具与受守卫的执行
- AI Copilot — 从应用外壳使用 Aura Bot
- Command Pipeline — 理解 Agent 动作如何安全执行
- Permission — 控制用户与 Agent 能做什么