
> 《ops-agent 建造笔记》第 14 篇（续篇分篇）
> 代码基线：[v0.1.0-rc.4](https://github.com/mengbin92/ops-agent/tree/v0.1.0-rc.4)，提交 `8dfa085`（2026-11-09 候选版）；前 13 篇仍固定 [v0.1.0-rc.1](https://github.com/mengbin92/ops-agent/tree/v0.1.0-rc.1)
> 对照实现：`agent/a2a_executor.py`、`agent/a2a_server.py`、`agent/a2a_client.py`、`agent/tools.py`、`requirements-a2a.txt`

---

## 0. 第 10 篇数到四，rc.2 加了第五个

第 10 篇把 REPL、单发、RPC、MCP 摆在一张表里，特别说明「共同复用的是更下面的守门与状态能力」，而不是四份入口都跑同一份模型循环。到 `v0.1.0-rc.2`，多了一个 `opsagent a2a`：基于官方 `a2a-sdk` 1.3.0 的协议 1.0，用 AgentCard + JSON-RPC 把同一组受控能力暴露给别的 agent 或编排器，也能反向调用别人的 A2A agent（`serve / card / call / doctor`）。

代码 README 里「四种形态共享同一内核」那句还停在 rc.1 口径。第 10 篇数四个没错，因为它锁的就是那个 tag；第五个从这里开始算。这也是续篇不回改旧文的原因之一：数法变了，说清从哪个版本开始变就行。

这一篇只讲这个壳。它带来的问题很具体：没有终端，谁来点确认？

---

## 1. 复用的是同一份 loop，不是第五份内核

`agent/a2a_executor.py` 开头的三条映射里，第一条就是会话：A2A 的 `context_id` 变成 `a2a-<context_id>`，落在同一个 `sessions/` 目录，所以这里跑过的每一轮都能用 `/resume` 回看，前缀也避免和人手动开的 REPL 会话混在一起。

模型循环还是 `loop.run_turn()`。区别只是它同步阻塞，executor 一律用 `asyncio.to_thread` 丢到线程里跑——否则一次几十秒的排查就能把整个 event loop 连同其它任务一起堵死。工具注册表、`core.py` 的守门、审批戳、状态目录，也都还是原来那一套。

AgentCard 放在 `/.well-known/agent-card.json`，`skills` 直接从 `skills/` 目录生成。对方看到的能力清单，就是这台机器上真正能 `skill` 载入的 playbook，不是另写的一份宣传页。能力声明和实际可加载项对不上，是这类协议最容易骗人的地方，这里从源头上避开了。

所以第五个壳不是第五份内核，也不是第五份守门。变的是传输协议，以及「问人」这件事落在哪里。

---

## 2. 没有确认框，就把它变成协议状态

A2A 通道没有 REPL 那样的实时确认框，但没因此放开写操作，也没有把「没终端」当成无人值守的理由。

R0 只读命令照旧由 bash 工具内部的 `core.check()` 直通。模型要动 R1–R3 时，只能走 `ops_approve`；工具内部的 `ctx.ask_user()` 在这里被抛成 `NeedUserInput` 中断，任务停在 `TASK_STATE_INPUT_REQUIRED`，整张变更单随状态一起回给调用方。调用方带同一个 `task_id` 回一句「确认执行」，框架再次调用 `execute()`，走续跑分支才建戳执行。批准词沿用既有判定（`确认执行` / `确认` / `yes` / `y`），其它回答一律视为拒绝；拒绝路径不产生审批戳，也不留执行记录。

真正容易出错的不是有没有弹窗，而是一句 yes 到底批准了什么。rc.4 的三轮审查把它收紧成几条不变量：

- **答复只批准上一轮展示过的那一单**。确认身份由「工具名 + 完整归一化参数 + 解析后的执行环境」组成，`core.env_identity(env)` 把 kubeconfig、SSH identity/options 都算进去。命令、目标、快照路径、次数、影响面或执行环境任一变化，身份就对不上，必须重新进 `INPUT_REQUIRED`——不会出现「批准 A、模型改成 B 却生效」。
- **确认框逐条展示快照文件与命令**，不再只报数量。两份数量相同、路径不同的变更单，人本来就没法核对批准的是哪一份。
- **一次答复只批准一个待确认项**。模型在续跑轮里发起第二个变更会再次中断，不会被同一个「确认」顺带放行；这条还配了变异验证的不变量测试。
- **普通澄清会作废旧审批身份**。`ask_user` 展示任何普通问题都清空待确认映射，于是「继续只读诊断吗？」的 yes 不会再批准此前被拒绝的写变更。
- **`--read-only` 是真只读**。起服时改用无人值守只读工具集 `tools.SCHEDULED_TOOLS`，schema 与 dispatch 两层同时受限；即使目标机上已有合法审批戳，`ops_exec` 等写工具也不可见、不可用，戳不会被消费。只读承诺不靠「恰好没有确认通道」来间接实现。

还有一处与调度相反的设计：A2A 里 `ask_user` 永远可用，由调用方承担答复责任，所以「无人值守语义」不适用于这个形态；上面那条 `--read-only` 是显式开关，不是默认行为。

---

## 3. 依赖、监听与限额

依赖是单独算的。只有 A2A 需要 protobuf/starlette 等第三方包，装在 `requirements-a2a.txt`，要求 Python ≥ 3.10，SDK 懒加载；REPL、单发、RPC、MCP、巡检、调度、通知仍是零第三方依赖，缺依赖时给出安装命令并退出 2。CI 里补了独立 A2A job，真装 SDK 跑单测和 e2e（真实 uvicorn 服务端 + 官方客户端 + 桩 LLM）——此前这些用例在 CI 里是整批静默跳过的。

| 项 | 行为 |
| --- | --- |
| 监听 | 默认 `127.0.0.1`；`--host 0.0.0.0` 等非回环地址未配 `OPSAGENT_A2A_TOKEN` 直接拒绝启动，不是警告后继续跑 |
| 鉴权 | RPC 端点强制 `Authorization: Bearer <token>`，定长比较；AgentCard 公开（仅能力声明，不含主机与凭据） |
| 凭据 | token 只从环境变量或 `--token` 读；写进命令行会留在 `ps` 与 shell 历史 |
| 输入 | 单条消息 20,000 字符上限，超长直接拒绝，引导先用 logscan 粗筛或分段 |
| 背压 | 并发槽默认 2，等不到槽 30 秒明确报「服务繁忙」，不让调用方无限挂在 WORKING |
| 超时 | 单任务墙钟默认 600 秒，到点记 `FAILED` 而不是 `COMPLETED` |

---

## 4. 没做的部分也要写清楚

AgentCard 里 `streaming=false`：`SendStreamingMessage` 没做验证，就不往 card 上声明没验证过的能力。取消只标记状态，Python 线程无法中断，已发出的命令可能仍在目标机执行，因此取消消息明确要求「按执行记录核实」——这正是第 4 篇 unknown 语义在协议态里的样子。

任务状态在 `InMemoryTaskStore`，服务重启后旧 `task_id` 失效（会话仍在磁盘，可 `/resume` 看历史）；长期挂起的确认流程要接持久化 task store 才行。常驻会话表加了 200 上限和 LRU 淘汰，正在执行、持锁的会话不淘汰——`Session` 会缓存全部 messages，不设限等于长期运行的内存泄漏。

同一 token 下的调用方共享会话空间，这是单一信任域，不是多租户隔离；要给不互信的多方用，得在前面加网关，不要直接把这个端口开放出去。A2A 1.0 与 0.3 的方法名不兼容（`SendMessage` vs `message/send`），对端是 0.3 时需要它先升级，本版没开兼容开关。

最后提一句整体口径：本组续篇统一按 rc.4 写，真实模型调用与邮箱通知渠道已验收通过，但真实 SSH 恢复、断线 `unknown` 防重放、服务后验与修复版本七天观察仍未完成，W8 整体未通过。A2A 的 e2e 用的是桩 LLM 与本机服务端，不能替代这些外部验收；完整证据表放在[第 17 篇](17-notify-and-acceptance.md)。

### 对照源码与证据

- [A2A 协议形态、写操作确认与安全边界](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/README.md)
- [A2A executor：会话映射、二次确认与只读模式](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/agent/a2a_executor.py)
- [A2A 服务端](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/agent/a2a_server.py) · [A2A 客户端](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/agent/a2a_client.py)
- [可选依赖清单](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/requirements-a2a.txt)
- [只读工具集合与 ops_approve 确认身份](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/agent/tools.py)
- [rc.2 发布说明（A2A 首轮交付与 review 修复）](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/docs/releases/release-v0.1.0-rc.2.md) · [rc.4 发布说明（R01/R02/F01/F02）](https://github.com/mengbin92/ops-agent/blob/v0.1.0-rc.4/docs/releases/release-v0.1.0-rc.4.md)

《ops-agent 建造笔记》第 14 篇（续篇分篇） 代码基线：v0.1.0-rc.4，提交 8dfa085（2026-11-09 候选版）；前 13 篇仍固定 v0.1.0-rc.1 对照实现：agent/a2a_executor.py、agent/a2a_server.py、agent/a2a_client.py、agent/tools.py、requirements-a2a.txt

第五个壳，没有终端确认框

后端

人工智能

A2A协议壳复用同一内核，非第五份实现。无确认框时以协议状态机制保障写操作安全：确认身份绑定工具名、参数与执行环境，变更即失效。--read-only走独立只读工具集。依赖单独管理，默认回环监听并强制Bearer鉴权。取消仅标记状态，未声明未验证能力，任务状态存内存。

Python

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

第五个壳，没有终端确认框-腾讯云开发者社区-腾讯云

第五个壳，没有终端确认框

第五个壳，没有终端确认框

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐