6.2 设计题
给你一个真实场景，设计 Agent 的架构、模式和控制策略。没有标准答案，但有关键考量。
题目 1：设计一个代码审查 Agent
场景：你的团队每天有 10-20 个 PR 需要审查，你想设计一个 Agent 自动审查 PR 的代码质量、安全性和规范性。
设计要求：
- 这个 Agent 应该在哪个自主性级别运行？为什么？
- 你会选择什么设计模式？画出执行流程。
- 需要哪些工具？考虑 MCP Server。
- 怎么设置权限和终止条件？
- 人怎么介入？
参考设计
自主性 Level 2：Agent 可以自主分析代码，但所有修改建议需人工确认。理由：代码审查涉及判断，Agent 不应直接修改代码。
Plan-Execute + Reflexion：
Plan：制定审查清单（安全、性能、风格、业务逻辑） Execute：逐一审查每个文件 Reflexion：审查完后自检是否有遗漏工具：
- MCP GitHub Server：读取 PR 变更、获取文件内容
- 搜索工具：查找相关代码引用
- 静态分析工具：检测安全漏洞和代码风格
权限：
- 自动：读取 PR、搜索代码、运行静态分析
- 确认：标记问题、生成建议
- 禁止：修改代码、批准 PR
人类介入：
- Agent 生成审查报告后，由人类审查员最终确认
- 高风险问题（安全漏洞、数据泄露）必须人工复核
题目 2：设计一个项目迁移 Agent
场景：你有一个老旧的 JavaScript 项目，需要迁移到 TypeScript。项目有 50+ 个文件，你想让 Agent 批量处理。
设计要求：
- 这个任务的自主性级别？
- 你会用多 Agent 协作吗？如果用，怎么分工？
- 怎么处理迁移中可能出现的类型错误？
- 怎么验证迁移的正确性？
- 什么情况下应该人工介入？
参考设计
自主性 Level 2-3：类型声明和简单的迁移可自主，但复杂的类型推断和架构变化需确认。
多 Agent 协作——顺序模式：
Agent A（Explore）：分析项目结构和依赖关系 → Agent B（Plan）：制定迁移顺序（从叶子模块到核心模块） → Agent C（general-purpose）：逐文件迁移 → Agent D（general-purpose）：验证迁移结果类型错误处理：
- 简单类型错误（缺少类型声明）→ Agent 自动添加
- 复杂类型推断（泛型、联合类型）→ Agent 建议，人工确认
- 无法推断的类型 → 标记
any并记录待处理
验证方式：
- 每迁移完一个文件，运行
tsc --noEmit检查类型错误 - 运行现有测试套件，确保功能不变
- 每完成一个模块，人工抽查关键文件
- 每迁移完一个文件，运行
人工介入场景：
- 迁移涉及架构变化（如从 class 迁移到函数式）
- 类型推断结果不确定
- 测试失败且 Agent 两次修正仍未解决
题目 3：设计一个安全审查 Agent
场景：你的公司需要定期审查代码库的安全漏洞（SQL 注入、XSS、敏感信息泄露等）。
设计要求：
- 自主性级别？
- 怎么设计权限，确保 Agent 本身不会成为安全风险？
- 怎么处理 Agent 发现的高危漏洞？
- 怎么评估 Agent 的审查质量？
- 与现有安全工具（SAST/DAST）怎么配合？
参考设计
自主性 Level 1：只读分析，提出建议，不执行任何修改。安全审查的最高原则是「观察不干预」。
权限设计：
- 只能读取代码，不能写入
- 不能访问生产环境数据
- 数据库连接使用只读账户
- MCP Server 只暴露只读 API
- 禁止联网（防止泄露代码到外部）
高危漏洞处理：
- 发现高危漏洞 → 立即通知安全团队（不自动修复）
- 生成漏洞报告（含代码位置、风险等级、修复建议）
- 跟踪修复进度，修复后重新审查
审查质量评估：
- 用已知漏洞的代码库做基准测试
- 对比 Agent 与人工审查的检出率
- 定期交叉审查（Agent 审查过的代码由人工复检）
与 SAST/DAST 配合：
- Agent 补充 SAST 无法覆盖的逻辑漏洞（如认证绕过）
- SAST 处理模式匹配型漏洞（如已知 CVE）
- DAST 验证运行时漏洞
- 三者结果汇总到统一的安全仪表盘