602 lines
18 KiB
Markdown
602 lines
18 KiB
Markdown
# RCoder Agent 抽象层重构方案分析
|
||
|
||
## 设计文档概述
|
||
|
||
本文档对 `specs/agent-abstraction-layer-design.md` 中提出的 Agent 抽象层重构方案进行深入分析,评估其可行性、潜在风险以及实施路径。
|
||
|
||
## 当前工程架构理解
|
||
|
||
### 核心技术特点
|
||
|
||
1. **ACP 协议约束**
|
||
- ClientSideConnection 和 AgentSideConnection 不实现 Send trait
|
||
- 必须在 LocalSet 中使用 spawn_local
|
||
- 当前采用子进程方式启动 Agent(如 claude-code-acp)
|
||
|
||
2. **状态管理模式**
|
||
- 使用 DashMap 替代 Arc<RwLock<HashMap>>
|
||
- PROJECT_AND_AGENT_INFO_MAP 全局状态管理
|
||
- AgentStatus 枚举: Active/Idle/Terminating
|
||
|
||
3. **生命周期管理**
|
||
- AgentLifecycleGuard 实现 RAII 模式
|
||
- CancellationToken 协调停止逻辑
|
||
- 子进程通过 kill_on_drop 自动清理
|
||
|
||
4. **MCP 服务器集成**
|
||
- create_default_mcp_servers 硬编码配置
|
||
- context7 和 fetch 作为默认 MCP 服务器
|
||
- 直接通过 ACP 协议传递给 Agent
|
||
|
||
5. **系统提示词**
|
||
- SystemPromptConfig 结构化管理
|
||
- PromptBuilder 动态构建提示词
|
||
- 包含前端开发约束和框架识别逻辑
|
||
|
||
## 重构方案关键设计分析
|
||
|
||
### 优势评估
|
||
|
||
#### 1. 配置化驱动的灵活性
|
||
|
||
**设计亮点:**
|
||
- Agent、MCP 服务器、系统提示词统一通过 JSON 配置
|
||
- 环境变量映射系统实现标准化(如 `{MODEL_PROVIDER_API_KEY}`)
|
||
- 支持多个 Agent 配置共存(react-developer、rust-expert 等)
|
||
|
||
**可行性分析:**
|
||
- ✅ 当前 AgentType 枚举硬编码的问题确实存在
|
||
- ✅ ModelProviderConfig 字段映射设计合理
|
||
- ⚠️ 需要考虑配置文件解析性能(冷启动)
|
||
- ⚠️ 配置验证逻辑复杂度较高
|
||
|
||
#### 2. 模块化 Crate 架构
|
||
|
||
**设计亮点:**
|
||
- `crates/agent_manager` - Agent 配置和生命周期管理
|
||
- `crates/mcp_validator` - MCP 服务器验证 lib 库(本次仅提供验证能力,不在 Agent 启动流程调用)
|
||
- 独立 lib 库供 rcoder、agent_runner 复用
|
||
|
||
**可行性分析:**
|
||
- ✅ 符合 Rust 模块化最佳实践
|
||
- ✅ 降低模块间耦合
|
||
- ✅ mcp_validator 作为基础设施库,后续通过新接口按需调用,不影响启动性能
|
||
- ⚠️ 增加编译时间和依赖管理复杂度
|
||
- ⚠️ 需要仔细设计 trait 边界避免循环依赖
|
||
|
||
#### 3. ACP 连接池管理
|
||
|
||
**设计亮点:**
|
||
- 使用 DashMap<String, Weak<AgentConnection>> 避免死锁
|
||
- 原子操作(AtomicInstant、AtomicU8)替代 Mutex
|
||
- 后台清理任务自动回收空闲连接
|
||
|
||
**可行性分析:**
|
||
- ✅ 避免重复创建昂贵的 ACP 连接
|
||
- ✅ Weak 引用防止内存泄漏
|
||
- ⚠️ LocalSet 嵌套管理复杂度高
|
||
- ⚠️ 连接复用可能导致会话状态混乱
|
||
- ❌ **重大风险**: RefCell 在多线程环境下不安全
|
||
|
||
### 风险识别
|
||
|
||
#### 高风险项
|
||
|
||
**1. ACP 连接池的 LocalSet 线程池管理**
|
||
|
||
```rust
|
||
pub struct AgentConnection {
|
||
local_set: Box<LocalSet>,
|
||
client_conn: RefCell<Option<ClientSideConnection>>,
|
||
// ...
|
||
}
|
||
```
|
||
|
||
**设计目标:**
|
||
- 避免死锁(使用 DashMap + Weak 引用 + 原子操作)
|
||
- 满足 ACP 协议约束(ClientSideConnection 必须在 LocalSet 中运行,不能跨线程)
|
||
- 通过 LocalSet 线程池实现连接管理
|
||
|
||
**技术要点:**
|
||
- RefCell 用于满足 LocalSet 内部的内部可变性需求,AgentConnection 只在 LocalSet 单线程内使用,因此 RefCell 是安全的
|
||
- DashMap 提供外层的线程安全访问,管理多个 AgentConnection 的弱引用
|
||
- Weak 引用避免循环依赖和内存泄漏
|
||
- 原子操作(AtomicInstant、AtomicU8)实现无锁状态管理
|
||
- **关键设计**：AgentConnection 本身不会被多线程访问,所有操作都在其专属的 LocalSet 中执行
|
||
|
||
**可行性评估:**
|
||
- ✅ 设计合理,符合 ACP 协议约束
|
||
- ✅ 通过 DashMap + 原子操作避免死锁
|
||
- ✅ RefCell 安全性已确认：AgentConnection 只在 LocalSet 单线程内访问
|
||
- ⚠️ 需要 PoC 验证 LocalSet 嵌套和连接复用的正确性
|
||
- ⚠️ 建议增加会话隔离验证,确保连接复用不会导致状态污染
|
||
|
||
**2. 系统提示词模板的变量替换**
|
||
|
||
```rust
|
||
result = result.replace("{MODEL_PROVIDER_ID}", &context.model_provider.id);
|
||
result = result.replace("{MODEL_PROVIDER_NAME}", &context.model_provider.name);
|
||
// ... 多次字符串替换
|
||
```
|
||
|
||
**业务优先原则:**
|
||
- 先确保业务逻辑正确性,性能优化是次要考虑
|
||
- 如果业务逻辑不正确,性能再快也没用
|
||
|
||
**性能优化选项(可选):**
|
||
|
||
Rust 生态中有多个成熟的模板引擎可供选择:
|
||
|
||
1. **MiniJinja** (推荐用于运行时模板)
|
||
- 性能优异(号称 10x Jinja2)
|
||
- 最小依赖,轻量级
|
||
- Jinja2 语法兼容
|
||
- 适合动态配置的系统提示词场景
|
||
|
||
2. **Tera**
|
||
- 功能丰富(继承、宏、过滤器)
|
||
- 运行时解析,灵活性高
|
||
- 社区成熟,3.8k+ stars
|
||
- 语法类似 Jinja2/Django
|
||
|
||
3. **Handlebars**
|
||
- 简单易用,逻辑少
|
||
- 跨语言兼容性好
|
||
- 适合简单模板场景
|
||
|
||
4. **Askama** (编译时模板)
|
||
- 最高性能(预编译)
|
||
- 编译时类型检查
|
||
- 但不适合动态配置场景
|
||
|
||
**实施建议:**
|
||
- ✅ 系统提示词模板是完整内容(3000+ 行),通过函数预处理成文本后使用
|
||
- ✅ 变量替换使用 `{}` 花括号格式,如 `{MODEL_PROVIDER_API_KEY}`
|
||
- ✅ 模板可以通过外部函数处理,最终目的是按 JSON 配置格式便捷修改
|
||
- 阶段 1: 使用简单 replace 实现,确保业务正确性
|
||
- 阶段 2(可选): 如性能成为瓶颈,考虑引入 MiniJinja 或 Tera
|
||
- 性能基准: 大型提示词(3000+ 行)渲染时间 < 10ms 为可接受
|
||
|
||
#### 中风险项
|
||
|
||
**1. 配置文件向后兼容性**
|
||
|
||
当前方案通过 DefaultConfigGenerator 生成默认配置,但:
|
||
- 新旧配置格式共存期间如何处理?
|
||
- 用户手动修改配置后升级如何迁移?
|
||
- 配置文件版本管理策略?
|
||
|
||
**建议:**
|
||
- 引入配置文件版本号字段
|
||
- 实现配置自动迁移逻辑
|
||
- 提供配置验证 CLI 工具
|
||
|
||
**2. Agent 空闲状态检测准确性**
|
||
|
||
```rust
|
||
pub fn is_agent_idle(&self, agent_id: &str) -> Option<bool> {
|
||
self.agent_status_map.get(agent_id)
|
||
.map(|info| matches!(info.status, AgentStatus::Idle))
|
||
}
|
||
```
|
||
|
||
**状态更新机制:**
|
||
- ✅ 状态更新是异步的,但必须放在队列中确保 MPSC 顺序
|
||
- ✅ 发送 Prompt 前先更新状态为 Active,然后再发送给 Agent
|
||
- ✅ 简化设计：不使用状态版本号或时间戳,依赖 MPSC 保证一致性
|
||
|
||
**潜在风险:**
|
||
- ⚠️ 如果状态更新消息在队列中延迟,可能短暂误判
|
||
- ⚠️ 需要确保状态更新消息优先级高于普通消息
|
||
|
||
**建议:**
|
||
- 使用 MPSC 队列确保状态更新的顺序性
|
||
- 状态更新操作应该是非阻塞的异步操作
|
||
- 考虑"预热"机制减少冷启动时间
|
||
|
||
### 设计缺陷与改进建议
|
||
|
||
#### 1. 过度工程化倾向
|
||
|
||
**问题:**
|
||
方案中包含大量高级特性(连接池、验证器、安装管理器),但实际需求可能不需要这么复杂:
|
||
- 容器环境下 Agent 随容器销毁,无需复杂状态管理
|
||
- MCP 服务器配置变更频率低,本次重构 mcp_validator 只提供 lib 能力不在启动路径上
|
||
- Agent 安装通常在镜像构建时完成
|
||
|
||
**建议:**
|
||
- MVP 阶段聚焦核心功能:配置化 + 环境变量映射 + 系统提示词
|
||
- 连接池作为后续优化项
|
||
- ✅ mcp_validator 仅作为 lib 提供验证能力,后续通过新接口按需调用,不在 Agent 启动路径上
|
||
- 简化 AgentManager,复用现有 PROJECT_AND_AGENT_INFO_MAP
|
||
- ✅ 环境变量冲突处理：如果 env 和 env_overrides 冲突,以 env_overrides 为准
|
||
|
||
#### 2. 缺少失败降级策略
|
||
|
||
**问题:**
|
||
方案中对配置解析失败、MCP 服务器启动失败等异常处理不明确:
|
||
- 配置文件损坏是否回退到默认配置?
|
||
- MCP 服务器部分失败是否允许 Agent 启动?
|
||
- Agent 启动失败如何通知用户?
|
||
|
||
**建议:**
|
||
- 定义明确的降级策略矩阵
|
||
- 关键错误拒绝启动,非关键错误记录警告
|
||
- 提供配置健康检查 API
|
||
|
||
#### 3. 测试策略不足
|
||
|
||
**问题:**
|
||
设计文档中缺少测试相关章节,但此类基础设施变更必须有完善的测试:
|
||
- 配置解析单元测试
|
||
- MCP 服务器集成测试
|
||
- Agent 生命周期端到端测试
|
||
|
||
**建议:**
|
||
- 每个 crate 的测试覆盖率 > 70%
|
||
- 使用 wiremock 模拟 MCP 服务器
|
||
- 引入混沌工程测试失败场景
|
||
|
||
## 实施路径建议
|
||
|
||
### 阶段划分重新调整
|
||
|
||
#### 阶段 0: 准备与验证(1 周)
|
||
|
||
**目标:** 验证核心技术可行性
|
||
|
||
**任务:**
|
||
1. PoC: 在独立分支验证 ACP 连接管理方案
|
||
2. 性能测试: 系统提示词模板渲染开销
|
||
3. 架构评审: 与团队确认模块划分
|
||
|
||
**交付物:**
|
||
- PoC 代码和性能报告
|
||
- 技术方案调整建议
|
||
|
||
#### 阶段 1: 配置系统基础(2 周)
|
||
|
||
**目标:** 建立配置化基础设施
|
||
|
||
**任务:**
|
||
1. 创建 `crates/agent_config` 基础库
|
||
2. 实现配置文件解析和环境变量映射
|
||
3. DefaultConfigGenerator 生成逻辑
|
||
4. 配置验证和错误处理
|
||
|
||
**交付物:**
|
||
- AgentServersConfig 数据结构
|
||
- EnvironmentVariableResolver
|
||
- 配置文件示例和文档
|
||
|
||
#### 阶段 2: 系统提示词模板化(1 周)
|
||
|
||
**目标:** 实现系统提示词配置化
|
||
|
||
**任务:**
|
||
1. SystemPromptConfig 结构调整
|
||
2. 模板变量替换逻辑
|
||
3. 兼容现有 system_prompt.rs
|
||
4. 用户提示词包装逻辑
|
||
|
||
**交付物:**
|
||
- 模板配置示例
|
||
- 性能优化(缓存机制)
|
||
- 单元测试
|
||
|
||
#### 阶段 3: MCP 服务器配置化(2 周)
|
||
|
||
**目标:** 实现 MCP 服务器动态配置
|
||
|
||
**任务:**
|
||
1. McpServerConfig 数据结构
|
||
2. 集成到 Agent 启动流程
|
||
3. ✅ mcp_validator crate 提供验证 lib 能力(仅作为库,不在 Agent 启动路径上调用)
|
||
4. 向后兼容 create_default_mcp_servers
|
||
5. ✅ 环境变量映射规则：env_overrides 优先于 env 配置
|
||
|
||
**交付物:**
|
||
- MCP 配置示例
|
||
- 配置加载逻辑
|
||
- 集成测试
|
||
|
||
#### 阶段 4: Agent 管理简化版(1 周)
|
||
|
||
**目标:** 简化的 Agent 管理接口
|
||
|
||
**任务:**
|
||
1. 创建 `crates/agent_manager` 轻量级版本
|
||
2. 封装现有 PROJECT_AND_AGENT_INFO_MAP
|
||
3. AgentConfig 与 AgentType 映射
|
||
4. 生命周期接口统一
|
||
|
||
**交付物:**
|
||
- AgentManager 简化实现
|
||
- 与现有代码集成
|
||
|
||
#### 阶段 5: 向后兼容与迁移(1 周)
|
||
|
||
**目标:** 确保平滑迁移
|
||
|
||
**任务:**
|
||
1. 兼容层实现
|
||
2. 配置自动生成逻辑
|
||
3. 迁移文档和工具
|
||
4. 端到端测试
|
||
|
||
**交付物:**
|
||
- 迁移指南
|
||
- 回滚方案
|
||
- 测试报告
|
||
|
||
### 技术债务处理
|
||
|
||
#### 延后到后续版本的特性
|
||
|
||
1. **Agent 安装管理器**: Docker 镜像构建时预装 Agent,运行时安装需求低
|
||
2. **MCP 服务器验证器**: ✅ 本次仅提供 lib 级别的验证能力,不在 Agent 启动路径上,后续通过独立接口调用
|
||
3. **Agent 热重载**: 容器化环境重启容器即可,热重载复杂度高
|
||
4. **系统提示词模板引擎**: ✅ 优先保证业务正确性,使用 String::replace 实现,如性能成为瓶颈再考虑引入 MiniJinja/Tera
|
||
5. **清理任务优化**: ✅ 参考现有项目的清理任务逻辑实现 ACP 连接池清理
|
||
6. **依赖注入简化**: ✅ 设计专门的配置结构体传递 AgentFactory 的 5 个依赖参数
|
||
|
||
#### 必须保留的设计
|
||
|
||
1. **配置化系统**: 核心需求,必须实现
|
||
2. **环境变量映射**: ✅ 标准化 ModelProviderConfig 映射,env_overrides 优先级高于 env
|
||
3. **系统提示词模板**: ✅ 解决硬编码问题,template 存储完整内容,通过函数预处理
|
||
4. **MCP 配置化**: 实现动态 MCP 服务器管理
|
||
5. **ACP LocalSet 线程池管理**: ✅ 通过 DashMap + 原子操作实现无锁连接管理,RefCell 在 LocalSet 单线程内安全
|
||
6. **Agent 状态管理**: ✅ 使用 MPSC 队列确保状态更新顺序性,发送前先更新为 Active
|
||
|
||
## 关键技术决策
|
||
|
||
### 决策 1: ACP 连接管理策略
|
||
|
||
**技术约束:**
|
||
- ACP 协议的 ClientSideConnection 不实现 Send trait
|
||
- 必须在 LocalSet 中运行,不能跨线程
|
||
- 需要通过 LocalSet 线程池管理多个 Agent 连接
|
||
|
||
**选项 A(原方案): LocalSet 线程池 + 连接复用**
|
||
- 优点: 减少进程创建开销,通过 DashMap + Weak + 原子操作避免死锁
|
||
- 风险: 需要验证连接复用的会话隔离正确性
|
||
|
||
**选项 B: LocalSet 线程池 + 进程管理(不复用连接)**
|
||
- 优点: 简单可靠,会话隔离明确
|
||
- 缺点: 进程创建开销
|
||
|
||
**决策:** 选择 A(原方案),理由:
|
||
- DashMap + 原子操作设计可以有效避免死锁
|
||
- 满足 ACP 协议的 LocalSet 约束
|
||
- 需要通过 PoC 验证连接复用的正确性和会话隔离性
|
||
- 如 PoC 发现会话隔离问题,可降级为选项 B
|
||
|
||
### 决策 2: 系统提示词模板引擎
|
||
|
||
**模板内容定位:**
|
||
- ✅ `SystemPromptConfig.template` 字段存储完整的系统提示词内容(3000+ 行)
|
||
- ✅ 可以通过外部函数预处理文本,然后存入配置
|
||
- ✅ 变量替换统一使用 `{}` 花括号格式
|
||
- ✅ 最终目标：通过 JSON 配置文件便捷修改和管理
|
||
|
||
**选项 A: 简单 String::replace**
|
||
- 优点: 实现简单,无依赖,业务逻辑清晰
|
||
- 缺点: 大型模板性能较低
|
||
|
||
**选项 B: MiniJinja**
|
||
- 优点: 性能优异(10x),最小依赖,Jinja2 语法
|
||
- 缺点: 增加依赖,学习成本
|
||
|
||
**选项 C: Tera**
|
||
- 优点: 功能丰富,社区成熟
|
||
- 缺点: 依赖较重,复杂度高
|
||
|
||
**决策:** 选择 A,理由:
|
||
- 业务正确性优先于性能优化
|
||
- 模板已经是预处理好的完整文本,只需简单变量替换
|
||
- 阶段 1 使用 String::replace 确保功能正确
|
||
- 阶段 2 如性能成为瓶颈(渲染 > 10ms),再引入 MiniJinja
|
||
- 通过性能监控数据驱动优化决策
|
||
|
||
### 决策 3: 配置文件格式
|
||
|
||
**选项 A:** JSON (原方案)
|
||
- 优点: 序列化简单,工具支持好
|
||
- 缺点: 不支持注释,大型配置可读性差
|
||
|
||
**选项 B:** TOML
|
||
- 优点: 支持注释,层级清晰
|
||
- 缺点: Rust 生态 JSON 支持更好
|
||
|
||
**选项 C:** YAML
|
||
- 优点: 简洁,支持注释
|
||
- 缺点: 缩进敏感,解析器复杂
|
||
|
||
**决策:** 选择 A(JSON),理由:
|
||
- 现有代码已使用 JSON(config.yml 实际是 YAML)
|
||
- serde_json 性能和生态最好
|
||
- 可通过外部工具转换带注释的 JSON5
|
||
|
||
### 决策 4: 模块划分粒度
|
||
|
||
**选项 A(原方案):** agent_manager、mcp_validator、agent_config 独立 crate
|
||
- 优点: 模块职责清晰
|
||
- 缺点: 编译时间长,依赖管理复杂
|
||
|
||
**选项 B:** agent_core 单一 crate 包含所有功能
|
||
- 优点: 编译快,依赖简单
|
||
- 缺点: 模块耦合
|
||
|
||
**决策:** 选择折中方案:
|
||
- `agent_config` crate: 配置解析和验证
|
||
- `agent_runner` 集成管理逻辑
|
||
- 不新增 mcp_validator crate
|
||
|
||
## 兼容性保障
|
||
|
||
### 向后兼容策略
|
||
|
||
#### API 层面
|
||
|
||
保持现有接口不变:
|
||
```rust
|
||
// 现有接口继续工作
|
||
pub async fn start_claude_code_acp_agent_service(
|
||
chat_prompt: ChatPrompt,
|
||
model_provider: Option<ModelProviderConfig>,
|
||
) -> Result<AcpConnectionInfo>
|
||
```
|
||
|
||
内部逐步切换到配置驱动:
|
||
```rust
|
||
// 内部实现使用新配置系统
|
||
impl ClaudeCodeAcpAgent {
|
||
async fn start_agent_service(...) -> Result<AcpConnectionInfo> {
|
||
let config = AgentConfigManager::load_or_default().await?;
|
||
// 使用配置启动 Agent
|
||
}
|
||
}
|
||
```
|
||
|
||
#### 配置层面
|
||
|
||
自动生成默认配置:
|
||
- 首次启动自动创建 `/etc/rcoder/agents.json`
|
||
- 配置内容与当前硬编码行为完全一致
|
||
- 用户可选择性修改配置
|
||
|
||
#### 行为层面
|
||
|
||
确保功能行为不变:
|
||
- MCP 服务器列表保持 context7 + fetch
|
||
- 系统提示词内容保持一致
|
||
- Agent 启动流程保持兼容
|
||
|
||
## 监控与可观测性
|
||
|
||
### 配置变更审计
|
||
|
||
记录所有配置相关事件:
|
||
- 配置文件加载成功/失败
|
||
- 环境变量解析结果
|
||
- Agent 启动使用的最终配置
|
||
|
||
### 性能指标
|
||
|
||
监控关键性能指标:
|
||
- 配置解析耗时
|
||
- Agent 启动耗时
|
||
- MCP 服务器连接时间
|
||
- 系统提示词渲染耗时
|
||
|
||
### 错误追踪
|
||
|
||
分类错误处理:
|
||
- 配置错误: 详细错误位置和原因
|
||
- MCP 错误: 哪个服务器失败及影响
|
||
- Agent 启动错误: 完整环境上下文
|
||
|
||
## 文档与培训
|
||
|
||
### 用户文档
|
||
|
||
1. **配置指南**
|
||
- agents.json 完整配置说明
|
||
- 环境变量映射规则
|
||
- 常见配置示例
|
||
|
||
2. **迁移指南**
|
||
- 从硬编码到配置化的步骤
|
||
- 配置验证方法
|
||
- 故障排查
|
||
|
||
3. **最佳实践**
|
||
- 如何定制系统提示词
|
||
- MCP 服务器选择建议
|
||
- 性能优化技巧
|
||
|
||
### 开发者文档
|
||
|
||
1. **架构文档**
|
||
- 模块依赖关系图
|
||
- 配置加载流程
|
||
- Agent 生命周期管理
|
||
|
||
2. **API 文档**
|
||
- AgentManager 接口说明
|
||
- 配置结构体字段说明
|
||
- 错误类型定义
|
||
|
||
3. **扩展指南**
|
||
- 如何添加新的 Agent 类型
|
||
- 自定义 MCP 服务器集成
|
||
- 系统提示词模板扩展
|
||
|
||
## 总结与建议
|
||
|
||
### 方案总体评价
|
||
|
||
**优点:**
|
||
- ✅ 系统性解决硬编码问题
|
||
- ✅ 配置化设计理念正确
|
||
- ✅ 环境变量映射方案合理
|
||
- ✅ 向后兼容策略考虑周全
|
||
|
||
**缺点:**
|
||
- ⚠️ 部分设计过于复杂(安装管理器、热重载)
|
||
- ⚠️ ACP 连接复用需要 PoC 验证会话隔离
|
||
- ⚠️ 测试和监控策略需要补充
|
||
- ⚠️ 缺少性能影响评估
|
||
|
||
### 核心建议
|
||
|
||
1. **业务优先**: 先确保业务逻辑正确性,性能优化基于监控数据决策
|
||
2. **风险可控**: 通过 PoC 验证 ACP 连接管理,DashMap + 原子操作避免死锁
|
||
3. **完善测试**: 补充测试策略章节
|
||
4. **分阶段实施**: 按建议的 6 阶段推进,每阶段独立验证
|
||
|
||
### 优先级调整
|
||
|
||
**必须实现(P0):**
|
||
- 配置文件系统
|
||
- 环境变量映射
|
||
- 系统提示词模板化
|
||
- MCP 服务器配置化
|
||
|
||
**建议实现(P1):**
|
||
- 配置验证和错误处理
|
||
- AgentManager 简化版
|
||
- 向后兼容层
|
||
- ACP LocalSet 线程池管理
|
||
|
||
**可选实现(P2):**
|
||
- MCP 服务器验证器(lib 能力)
|
||
- Agent 安装管理器
|
||
- 系统提示词模板引擎(MiniJinja/Tera)
|
||
|
||
**延后实现(P3):**
|
||
- Agent 热重载
|
||
- 配置热更新
|
||
- 高级监控指标
|
||
|
||
### 下一步行动
|
||
|
||
1. 与团队评审本分析文档
|
||
2. 确定最终技术方案和范围
|
||
3. 启动阶段 0 的 PoC 验证
|
||
4. 制定详细的任务分解和排期
|
||
|
||
---
|
||
|
||
**置信度评估:** 中等
|
||
|
||
**评估依据:**
|
||
- 对当前工程架构的理解充分
|
||
- 识别出关键技术风险点
|
||
- 提出了可行的简化方案
|
||
- 但 ACP 连接管理细节需要 PoC 验证
|
||
- 性能影响需要实测数据支撑
|
||
|
||
**建议:** 在正式实施前完成阶段 0 的技术验证,根据 PoC 结果调整方案细节。
|