苦猿技术分享 · 多 Agent 协作的 GitHub 体检工具——48 小时笔试题深度拆解▲ 学员发来的笔试题前言深夜 11 点学员甩过来一张截图上周三晚上 11 点我正在改一份 PPT。微信叮地响了一下我辅导的一个学员发了张截图过来——某家公司的工程师笔试题。48 小时内交卷。题目就一句话用 AI 编程工具做一个 Web 应用输入一个 GitHub 仓库 URL多 Agent 协作产出一份结构化的体检报告。我盯着这张图看了两分钟第一反应不是这题难不难而是——这题出得太狠了。它表面上是做个小工具实际上把现在 AI 工程岗最看重的几样东西全考了一遍多 Agent 编排LangGraph / LangChain / AutoGen异步实时通信SSE / WebSocketPrompt 工程结构化输出、角色分工、交叉评估工程交付能力README、运行指南、commit 历史Vibe Coding 认证让你交 3-5 条关键 Prompt任何一项糊弄都会被有经验的面试官一眼看穿。学员问我猿哥这题 48 小时能搞定吗我说能。但不是从零开始搞。接下来这一篇我把这道题的踩分点、坑位、和我陪学员最终交付的DeepEye项目截图你们看到了一次性拆给你看。不管你是正在求职的应届生、转行人还是正在做 AI 应用开发的同行——这篇都值得你啃完。▲ DeepEye 项目主界面三 Agent 协作 时间轴PART 01先拆题——考官到底想看你交什么很多人一拿到这种开放题第一反应是赶紧动手写代码。这是最大的错误。48 小时的笔试前 2 小时必须是拆题——把考官想要什么翻译成我要交付什么。我把这道题的得分点拆成三层基础分不交就出局输入界面能接收 GitHub 仓库 URL后端拉数据通过 GitHub API 拿 Star / Fork / 语言分布拿仓库内容README.md、源代码结构至少三个 Agent 协作Agent A代码分析评估代码复杂度、可维护性Agent B产品分析评估 README 质量、亮点Agent C综合评分汇总 A、B给出 0-100 分 优化建议这层你做不到后面都白搭。加分项拉开差距的关键题面里有一句很不起眼的话加分项采用异步式传输SSE 或 WebSockets将后台每个 Agent 的参考过程或阶段性报告实时发送到前端界面避免全量等待。90% 的候选人会跳过这一项。为什么因为做 SSE/WebSocket 意味着你要解决前后端的实时通信、Agent 状态管理、事件分发——工作量直接翻倍。但这一项恰恰是面试官用来筛人的钩子。交了说明你不仅能写代码还懂用户体验、懂工程权衡。隐藏 KPI决定能不能拿 offer题面最后还有两行小字Vibe Coding 过程认证提供使用 AI Coding 工具编程过程中的 3-5 条关键提示词Prompt。提交历史提交的文本。这两条是真正考你工程师素养的地方。你有没有清晰的 commit 历史还是一坨update你交的 Prompt 是帮我写代码这种废话还是带角色、目标、约束、验收标准的结构化 Prompt你的 README 能不能让人 5 分钟内本地跑起来一句话——考官不是看你能不能写出来是看你像不像一个能独立交付的工程师。代码只是载体交付方式才是评分项。PART 02架构怎么搭——LangGraph 三 Agent 流水线拆完题下一步是定架构。多 Agent 编排市面上有三个主流选择LangChain Agent上手快但流程不透明调试地狱AutoGen对话式编排适合多轮讨论不适合流水线场景LangGraph状态机模型节点之间共享 state可观测、可重放这道题是典型的流水线场景A、B 并行 → C 汇总闭眼选 LangGraph。流水线设计我给学员画的架构图是这样的URL 输入 ↓ [URL 解析] → 识别 owner/repo ↓ [GitHub 拉取] → API 元数据 文件树 ↓ [静态分析] → radon 圈复杂度 cloc 注释率 ↓ ┌─────────── 并行 ───────────┐ │ │ [Agent A · 代码审计] [Agent B · 产品价值] 分数 0-100 分数 0-100 └────────────┬─────────────┘ ↓ [Agent C · 综合裁判] 汇总 强制交叉评估 ↓ 结构化体检报告核心代码长这样from langgraph.graph import StateGraph from typing_extensions import TypedDict class RepoState(TypedDict): url: str owner: str repo: str files: list metrics: dict # radon / cloc 静态指标 agent_a_report: dict # 代码审计结果 agent_b_report: dict # 产品价值结果 final_report: dict # Agent C 汇总 graph StateGraph(RepoState) graph.add_node(parse_url, parse_url) graph.add_node(fetch_repo, fetch_repo) graph.add_node(static_analysis, static_analysis) graph.add_node(agent_a, agent_a_code_audit) graph.add_node(agent_b, agent_b_product_value) graph.add_node(agent_c, agent_c_judge) graph.add_edge(parse_url, fetch_repo) graph.add_edge(fetch_repo, static_analysis) # 静态分析后A、B 并行 graph.add_edge(static_analysis, agent_a) graph.add_edge(static_analysis, agent_b) # A、B 都完成后再跑 C graph.add_edge([agent_a, agent_b], agent_c) app graph.compile()一个关键设计点Agent C 必须换模型这是我反复跟学员强调的一条——Agent C 用的模型必须跟 A、B 不同 family。为什么如果 A、B、C 都用 GPT-4o它们会有同源盲区——同一类问题它都看不见。比如 GPT-4o 容易高估目录结构清晰度那 A、B、C 三个都会高估最终分数虚高。我们最终的配置是Agent A、BGPT-4o / Claude Sonnet快、便宜、上下文够用Agent C换成不同 family 的模型比如 DeepSeek、Qwen这叫交叉评估。同一份报告让两个不同训练数据的模型各自打分分歧才会暴露。这一招在面试讲架构时一拿出来面试官眼睛会亮。PART 03踩坑实录——SSE 实时推送与 Agent 状态可视化加分项要拿但 SSE 这条路是真不好走。学员在跑通输入 URL → 出报告的同步版本后花了整整一天才把 SSE 串起来。我把踩过的三个坑都记下来。坑 1LangGraph 同步 invoke 会阻塞事件循环最直觉的写法是这样# 错误写法会阻塞 app.get(/api/analyze) async def analyze(url: str): async for event in app.astream_events(input, versionv2): yield format_event(event) return result # ❌ 这里 return 早了问题在于 LangGraph 的astream_events是事件流但 FastAPI 的app.get不能直接返回 generator。正确写法是用StreamingResponsefrom fastapi.responses import StreamingResponse app.get(/api/analyze) async def analyze(url: str): async def event_stream(): async for event in graph_app.astream_events( {url: url}, versionv2 ): kind event[event] if kind on_chain_start: yield fevent: stage\ndata: {json.dumps({node: event[name]})}\n\n elif kind on_chain_end: yield fevent: report\ndata: {json.dumps(event[data])}\n\n return StreamingResponse(event_stream(), media_typetext/event-stream)前端用原生EventSource监听按event:字段分发就行。坑 2Agent 并发与状态合并A、B 并行跑C 必须等齐。这个 LangGraph 的add_edge([a, b], c)语法已经帮你处理了——它会等 a、b 都 done 才触发 c。但报错处理得自己写。Agent B 报错了怎么办我们的降级策略给 B 一个默认分50 分在最终报告里标记产品价值评估降级不阻塞整体流程工程化的核心就是——LLM 会失败但你的服务不能挂。坑 3评分稳定性这是最坑的一个。同样的仓库跑两次分数差 ±15 分。为什么LLM 评分天生漂移。解法有三结构化输出用 JSON schema 约束输出格式分数必须是数字、维度必须齐few-shot 锚点在 prompt 里给 2-3 个已知答案的样本让模型对齐刻度温度调到 0.2牺牲一点创造性换稳定性跑完这三步分数波动能压到 ±3 分以内。▲ 执行时间轴每个 Agent 的状态实时回传PART 04交付物的卖相——让考官挑不出毛病的体检报告代码跑通只完成了一半。报告长什么样决定了你能不能拿满分。评分维度不能拍脑袋很多人让 LLM 直接输出一个 0-100 分这是大忌——面试官看到87 分第一反应是凭什么 87标准在哪正确的做法是把评分维度拆开每个维度带权重维度权重说明architecture架构25%目录结构、模块化、技术栈合理性quality代码质量25%复杂度、注释率、可读性documentation文档20%README 完整度、注释覆盖率activity活跃度15%commit 频率、最近维护情况security安全15%密钥泄露、依赖漏洞权重写在 prompt 里让 LLM 按这个表打分输出的分数就有了依据。报告必须有的几个块最终交付的体检报告参考截图 3应该包含总分 评级A/B/C/D5 维评分表维度 / 分数 / 权重 / 说明亮点绿色3-5 条风险黄色/红色3-5 条改进建议每条对应一个风险优先改进清单 P0/P1/P2最后这个P0/P1/P2 优先级清单是杀手锏。它把 LLM 输出的散装建议工程化成了按优先级排好的行动项——P0必须立刻处理密钥泄露这种P1本周内处理重构并发逻辑、补文档P2长期改进加测试、补注释面试官看到这个清单的瞬间他知道你不只是调了个 API你是真懂工程交付。Vibe Coding 认证Prompt 怎么交题面要求交 3-5 条关键 Prompt。别交这种帮我写一个分析 GitHub 仓库的 Agent这种 Prompt 一交直接暴露你不会用 AI。要交这种角色 目标 约束 验收标准你是 Agent A · 代码审计专家。 ## 目标 对给定的 GitHub 仓库进行代码层面的健康度评估。 ## 输入 - 仓库 owner / repo - 核心文件列表15 个 - 静态分析指标radon 圈复杂度、cloc 注释率 ## 输出格式严格 JSON { score: 0-100 的整数, highlights: [亮点 1, 亮点 2], risks: [风险 1, 风险 2], suggestions: [建议 1, 建议 2] } ## 评分锚点 - 90架构清晰、测试覆盖 70%、注释率 30% - 70-89架构合理但有瑕疵 - 50-69明显技术债 - 50严重不可维护这种 Prompt 一交出去面试官就知道——这人不是在用 AI是在驾驭 AI。▲ 最终交付的体检报告5 维评分 优先改进清单结尾笔试题考的从来不是答案回到这道 48 小时的笔试题。我陪学员交完卷的那一刻他问我猿哥你觉得能过吗我说你已经赢了。不是因为你做出了 DeepEye 这个项目而是因为你完整经历了一次从需求拆解到工程交付的全流程——拆题、架构、SSE、多 Agent、结构化输出、降级策略、报告工程化、Prompt 认证……这些才是面试官真正想看的东西。笔试题考的从来不是答案是你交付答案的方式。多 Agent 不是把 LLM 调三次而是把分工这件事写进代码。代码会过时框架会迭代但像工程师一样思考问题的能力永远不过时。互动时间你遇到过最狠的笔试题是什么是这种开放题还是纯算法题评论区聊聊我挑两条下次专门拆。关注我下一期拆多 Agent 落地的 5 种编排模式——什么场景该用 Pipeline什么场景该用 Supervisor什么场景必须上 Swarm。— END —苦猿 · 帮普通人把 AI 学进简历