AsterASTER ACP / 协议原理
事件投影与确认身份
文本、推理、工具预告、执行开始、结果与权限回答的身份映射。
界面显示的是运行投影
Core 产生执行事件。 ACP 根据事件构造协议更新。 客户端根据原始 ID 更新已有内容。 同一次调用的预告与执行开始应归到同一身份。
- 01文本增量直接流向界面
TextDelta 形成用户可见消息增量。
turn.rsL26 ↗ - 02参数就绪后建立工具行
ToolStart 只有预告。ToolExecutionStart 才带实际参数。
- 03用原 ID 更新结果
ToolEnd 更新同一工具行。重复预告不会新增一次执行。
每类 Core 事件怎样映射
| Core 事件 | ACP 处理 | 客户端含义 |
|---|---|---|
TextDelta | 发出消息文本增量 | 追加答复文本 |
ReasoningDelta | 发出思考增量 | 与答复文本分开显示 |
ToolStart | 不建立重复工具行 | 该事件尚无完整参数 |
ToolExecutionStart | 创建或更新原工具行 | 参数已准备就绪 |
ToolOutputDelta | 更新原工具输出 | 按调用 ID 追加输出 |
ToolEnd | 更新调用终态和结果 | 保留输出、退出码与元数据 |
ConfirmationRequired | 关联原 ID 并发起权限请求 | 显示准确的一次调用 |
painted_tools 记录已显示的工具身份。
适配器据此区分新建与更新。
同响应中的重复调用拒绝也有专门处理。
客户端不能用“每收到一个事件就新增一行”代替映射。
源码：事件分发 L26 ↗。
为什么 ToolStart 不立即建立工具行
流式输出可能先宣布一次工具调用。 此时，完整参数尚未到达。 随后事实执行器会宣布实际执行开始。 若两个事件各建一行，同一次执行就会重复显示。
当前适配器等待 ToolExecutionStart 的准确参数。
收到更新时继续使用原始调用 ID。
工具结果到达后，适配器更新同一行。
这项规则也保留同响应去重的实际结果。
一次确认的完整路径
- 01构造准确的请求
请求包含会话 ID、工具 ID 和参数。
permission_ask.rsL11 ↗ - 02显示并取得明确回答
客户端按代理提供的选项显示界面。
- 03只回答原来的调用
返回选项 ID 后，适配器把回答交给 Core。
请求包含会话 ID、工具调用 ID 和准确参数。
tool_permission_ask 还构造说明与可用选项。
客户端应显示代理提供的选项。
回答使用原始选项 ID。
| 常见选项 | 何时出现 | 作用范围 |
|---|---|---|
allow-once | 本次调用支持批准 | 当前请求 |
allow-always | 命令满足可学习规则 | 原工作区中的准确规则 |
reject-once | 当前请求支持拒绝 | 当前请求 |
并非每个工具都包含长期允许选项。
客户端不能自行生成未声明的选项。
源码：权限请求构造 L11 ↗。
迟到事件与取消怎样处理
用户取消后，客户端仍可能收到原运行的收尾事件。 适配器使用运行身份和当前轮次管理事件。 客户端也应按原会话与工具 ID 归档。 迟到的成功文本不能覆盖已经取消的另一轮运行。
取消权限对话与停止模型生成有不同对象。 前者回答原确认请求，后者控制原 Run。 两项操作都应保留准确的关联。
怎样验证客户端没有歪曲执行结果
- 提交一条纯文本消息。
- 核对文本增量所属会话。
- 触发一次需要确认的调用。
- 核对工具 ID 与原始参数。
- 拒绝本次调用。
- 检查工具行保留拒绝结果。
- 取消一轮正在执行的任务。
- 核对收尾事件的原始身份。
还应覆盖流结束但缺少终态事件的故障。 宿主应显示实际缺口，避免把静默断流显示成成功。 下一篇说明目标续跑和无人值守。