初始化 agent_ops 文档治理体系

2026-08-07 16:56:51 +08:00
commit 10840909ab
75 changed files with 15750 additions and 0 deletions
@@ -0,0 +1,65 @@
+# 跨项目迭代边界与协作方式
+
+**版本：** 2026-08-07  
+**适用范围：** 从 `04A.agent_tool_route` 开始的跨项目迭代
+
+## 1. 当前现实
+
+从 `04A` 开始，一次迭代已经不再只作用于 `lineup-app/`。
+
+一个完整闭环可能同时涉及：
+
+- `lineup-app/`：Runtime、Host、UI、SDK
+- `lineup-adapter/hermes/`：协议转换、Agent 兼容层
+- `lineup-app-server/`：必要时的传输边界
+- `agent_ops/`：规划、设计、协议与验收文档
+
+因此，迭代必须以“能力闭环”为单位，而不是以“某个仓库”命名。
+
+## 2. 规划时必须写清的三件事
+
+### 2.1 涉及哪些项目
+
+每份 `01.迭代规划.md` 都必须列清：
+
+- 主要改动项目；
+- 次要联动项目；
+- 只需验证、不需修改的项目。
+
+### 2.2 哪个项目负责什么
+
+规划和技术规范都要写清：
+
+- Runtime 责任；
+- Adapter 责任；
+- 服务端责任；
+- Host / 验收责任；
+- 文档与协议责任。
+
+### 2.3 哪些层不应被修改
+
+跨项目迭代最常见的问题，不是“漏改一个文件”，而是“把不该动的边界动了”。
+
+所以规划里必须明确：
+
+- 哪一层是执行权威；
+- 哪一层只做兼容；
+- 哪一层视为透明传输；
+- 哪些旧语义在本轮保持不变。
+
+## 3. 评审时的检查顺序
+
+跨项目迭代建议按以下顺序评审：
+
+1. 先看产品与架构边界是否清楚；
+2. 再看跨仓责任是否分清；
+3. 再看协议与状态机是否闭环；
+4. 最后看实施和验收能否真正跨端跑通。
+
+## 4. 当前统一入口
+
+从现在开始：
+
+- 迭代规划、设计评审、技术规范、技术评审都在 `agent_ops/03.迭代规划/` 下组织；
+- 具体实现仍分布在各代码仓；
+- 但“本次迭代到底在做什么”只在这里定义和冻结。