agent_ops/03.迭代规划/00.迭代方法/03.跨项目迭代边界与协作方式.md

跨项目迭代边界与协作方式

版本： 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.迭代规划/ 下组织；
• 具体实现仍分布在各代码仓；
• 但“本次迭代到底在做什么”只在这里定义和冻结。