让大模型
长出手脚

参考答案：

使用平台：通义千问（Qwen）

Agent 工具定义：

工具名	功能	参数
search_weather	查询目的地天气	city: string, date: string
search_attractions	搜索景点推荐	city: string, days: int
plan_itinerary	规划每日行程	attractions: list, days: int, weather: string
estimate_budget	估算旅行预算	city: string, days: int, itinerary: list

ReAct 循环过程：

用户输入："帮我规划一个北京 3 日游的行程"

【第 1 轮】
Thought: 用户需要北京 3 日游的规划。我首先需要知道北京这几天的天气情况，以便合理安排户外和室内活动。
Action: search_weather(city="北京", date="2024-10-15")
Observation: 10月15日晴，16-22°C；10月16日多云，14-20°C；10月17日小雨，12-18°C

【第 2 轮】
Thought: 天气情况已获取。前两天天气不错，适合户外活动；第三天有小雨，建议安排室内景点。接下来搜索北京的热门景点。
Action: search_attractions(city="北京", days=3)
Observation: 推荐景点包括：故宫、天安门广场、长城（八达岭）、颐和园、天坛、国家博物馆、798艺术区、南锣鼓巷、鸟巢水立方

【第 3 轮】
Thought: 景点列表已获取。现在需要根据天气和景点位置来规划每日行程。第一天天气晴朗，适合户外，安排故宫和天安门广场；第二天多云，可以去长城和颐和园；第三天有雨，安排国家博物馆和798艺术区（室内为主）。
Action: plan_itinerary(attractions=["故宫","天安门广场","长城","颐和园","国家博物馆","798艺术区"], days=3, weather="D1晴,D2多云,D3小雨")
Observation: 行程规划完成：  Day1（晴）：上午天安门广场 → 下午故宫博物院  Day2（多云）：上午八达岭长城 → 下午颐和园  Day3（小雨）：上午国家博物馆 → 下午798艺术区

【第 4 轮】
Thought: 行程已规划好，现在需要估算预算。北京 3 日游需要考虑交通、住宿、门票、餐饮等费用。
Action: estimate_budget(city="北京", days=3, itinerary=["天安门广场","故宫","长城","颐和园","国家博物馆","798艺术区"])
Observation: 预估预算：交通（含往返）800元 + 住宿（2晚）600元 + 门票 350元 + 餐饮 450元 = 总计约 2200元

【第 5 轮】
Thought: 所有子任务已完成：天气已查询、景点已推荐、行程已规划、预算已估算。现在可以汇总输出最终结果。
Final Answer:  北京 3 日游规划如下：  - 天气：D1晴16-22°C / D2多云14-20°C / D3小雨12-18°C  - 行程：D1 天安门广场+故宫 / D2 长城+颐和园 / D3 国家博物馆+798艺术区  - 预算：约 2200 元（含交通、住宿、门票、餐饮）  - 温馨提示：第三天有雨，请带好雨具，已安排室内景点为主。

评分标准（50 分）：

评分项	分数	评分标准
ReAct 循环完整性	20 分	至少 4 轮完整的 Thought→Action→Observation，每轮 5 分。缺少一轮扣 5 分。
工具定义合理性	10 分	工具名称清晰、参数定义合理、功能描述准确。每个工具 2.5 分。
流程逻辑性	10 分	各步骤之间有合理的逻辑依赖关系（如先查天气再规划行程），逻辑混乱扣 5-10 分。
平台选择	5 分	明确说明使用国内大模型平台（通义千问/文心一言/DeepSeek/Kimi 等），未说明扣 5 分。
输出完整性	5 分	最终有完整的汇总输出，格式清晰。缺少或格式混乱扣 3-5 分。

参考答案：

使用平台：DeepSeek（主 Agent）+ 通义千问（审查 Agent）

架构设计：多 Agent 层级协作模式（Hierarchical）

各 Agent 职责定义：

（1）调度 Agent（Supervisor Agent）—— DeepSeek

• 职责：接收用户提交的代码，将代码分发给各审查 Agent，收集审查结果，汇总生成最终审查报告
• 输入：待审查的代码文件
• 输出：综合审查报告（含问题汇总、严重程度分级、修改建议）

（2）代码风格 Agent（Code Style Agent）—— 通义千问

• 职责：检查代码是否符合团队编码规范（命名、缩进、注释、函数长度等）
• 输入：代码文件
• 输出：代码风格问题列表，包含具体位置和修改建议

（3）安全检查 Agent（Security Agent）—— 通义千问

• 职责：检查代码是否存在安全漏洞（SQL 注入、XSS、敏感信息泄露、权限校验缺失等）
• 输入：代码文件
• 输出：安全问题列表，按严重程度排序（高危/中危/低危）

（4）性能分析 Agent（Performance Agent）—— 通义千问

• 职责：分析代码性能瓶颈（不必要的循环、重复计算、内存泄漏风险、数据库查询优化等）
• 输入：代码文件
• 输出：性能优化建议列表

（5）文档审查 Agent（Documentation Agent）—— 通义千问

• 职责：检查函数/类是否有合理注释、接口文档是否完整、README 是否清晰
• 输入：代码文件 + 文档文件
• 输出：文档缺失/不清晰的问题列表

协作流程：

步骤 1：用户上传代码 → 调度 Agent 接收
步骤 2：调度 Agent 将代码同时分发给 4 个审查 Agent（并行执行）
步骤 3：各审查 Agent 独立分析，生成各自的审查结果
步骤 4：调度 Agent 收集所有审查结果
步骤 5：调度 Agent 对问题去重、合并、按严重程度排序
步骤 6：调度 Agent 生成综合审查报告，输出给用户

多 Agent 相比单 Agent 的优势：

对比维度	单 Agent 方案	多 Agent 方案（本设计）
审查覆盖面	一个 Agent 需同时关注风格、安全、性能、文档，容易遗漏	每个 Agent 专注一个领域，审查更深入
审查质量	审查深度受限于单个 Agent 的上下文窗口	每个 Agent 各自拥有完整上下文，分析更全面
容错性	如果 Agent 在某个领域判断失误，没有机制纠正	不同 Agent 可能发现同一问题的不同角度，互为补充
可扩展性	增加审查维度需要修改 Agent 的 prompt	只需新增一个专门的审查 Agent
并行效率	串行执行，等待时间长	4 个 Agent 并行审查，总耗时接近最慢的单个 Agent

评分标准（50 分）：

评分项	分数	评分标准
Agent 职责定义	15 分	至少包含 3 个不同职责的 Agent，每个 Agent 职责描述清晰。少于 3 个扣 10 分，职责描述不清每个扣 5 分。
协作流程设计	15 分	流程逻辑清晰，包含完整的分发→审查→汇总→输出流程。流程不完整扣 5-10 分，逻辑混乱扣 5-10 分。
多 Agent 优势分析	10 分	至少从 3 个维度对比单 Agent 与多 Agent 的差异。少于 3 个维度扣 5 分，分析不准确扣 3-5 分。
平台选择	5 分	明确说明使用国内大模型平台。未说明扣 5 分。
整体设计质量	5 分	整体设计合理、有创新性、具备实际落地价值。