没有Agent经验，怎么从0做出一个能写进简历的项目？

我做了六年产品经理，但不是科班出身。

没学过机器学习，没刷过 LeetCode，也没在大厂 AI 部门待过。

但我现在简历上有一个 Agent 项目。

它叫“小聆”，是一个客户声音智能分析平台。

如果你还不懂 Agent，可以先把它理解成一种不只会回答问题，还会围绕目标判断下一步、调用工具完成任务的 AI 系统。

小聆客户声音智能分析平台工作台

我能讲清楚它为什么只拆三个专业 Agent，为什么权限校验不能交给模型，哪个 Bug 让我重做了上下文，甚至能说清楚那 1000 条评测数据为什么不能直接叫“准确率”。

面试官继续往下问，我不会只剩一句“我用了 LangGraph”。

这篇文章想讲的，就是我怎么从一个不懂 Agent 的产品经理，慢慢做出一个能放进简历、也经得住追问的项目。

01 我一开始把学习顺序弄反了

很多人学 Agent，是先找教程，背怎么分配任务、怎么调用工具、怎么保存状态、怎么接知识库，以及什么时候让人介入。等觉得概念学得差不多了，再想做什么项目。

我一开始也觉得，技术名词得先学全，不然怎么动手？

但真开始做才发现，这些词单独看都懂，放到项目里却不知道该放在哪，也不知道到底需不需要。学了很多，真正动手的时候还是不会。

先做一个最小版本，再沿着真实问题把概念问懂。

后来我换成了这个顺序。这样每学到一个词，我都能在项目里指出它的位置，也知道少了它会出什么问题。

先做出最小版本，再沿着问题把Agent概念问懂

02 第一步：我先选了一个自己真懂的场景

小聆这个项目一开始其实定位是“风险分诊系统”。

它想解决的痛点是，企业每天会收到大量投诉、客服记录、商品评论和社交平台反馈。里面很多内容重复、情绪化、信息不完整，看起来像噪声，但也藏着产品缺陷、服务风险，甚至是一次正在扩散的品牌危机。

用户需要的，是从一堆吵闹的声音里，把值得处理的信息找出来。

但“分诊”更像是在做分类和流转，还没有回答用户拿到分类结果以后，到底能解决什么问题。

所以我重新把它定位成“小聆｜客户声音智能分析平台”。

目标也变得很清楚：从高噪声、多渠道的客户声音里，提炼值得关注的信号。

我重新梳理小聆的项目目标

这个就是做产品最重要的第一步：你的目标客户是谁，他们有什么问题，你准备通过什么方案解决。

接着我拆了三个用户角色。

产品经理关心功能缺陷、影响用户量和业务损失；运营关心处理流程、任务跟进和事件闭环；公关关心负面传播、品牌信任和对外回应边界。

同一条投诉，三种人看到的重点完全不同。

这一步还没有 LangGraph，也没有 Agent 架构图，但它决定了后面的 Agent 到底替谁判断，又要把结果交给谁。

如果你还没有自己的场景，也可以从熟悉的工作里找。

客服每天在重复回答什么？销售找资料时最慢的是哪一步？招聘人员筛简历时最耗时间的判断是什么？法务查合同的时候，哪些信息最容易漏？

场景不需要听起来很大。

“帮售前从产品资料里找到匹配的案例”，往往比“做一个全能销售 Agent”更适合拿来做第一版。

标准只有一个：你得对这个场景有感觉，能看得出它哪里不对。

03 第二步：我先做产品设计，再让AI写代码

场景定下来以后，我没有马上让 AI 开始写代码。

我先把小聆拆成了新建分析、事件详情、任务中心、人工复核、知识库、评估与迭代、权限管理几个模块。但第一版不可能把这些全部做完，所以我先盯住一条最核心的业务链路：

输入一条客户反馈 → 判断它属于哪类问题 → 调用对应的专业 Agent → 补充企业知识和历史案例 → 判断风险 → 决定是否需要人工复核 → 生成分析报告。

这条链路确认以后，我才让 AI 帮我拆架构和代码。我没有让它一口气生成整个项目，因为这样看起来很快，后面一报错，你根本不知道该从哪一层找。

我先让它只出方案：

我想做一个【你的场景】Agent。用户是【用户角色】，他最想完成的任务是【具体任务】。请先帮我拆出一条最小可运行的业务链路，只保留完成这个任务必需的模块。说明每个模块解决什么问题、输入和输出分别是什么，暂时不要写代码。不要为了展示技术，默认加入多个 Agent 协作、长期记忆或复杂工作流。

等方案确认以后，再按模块实现：

按照刚刚确认的方案开始实现。先跑通最核心的一条链路，再补其他功能。每完成一个模块，告诉我改了哪些文件、怎么启动、怎么验证、出错时先看哪里。

第一版简陋一点没关系，但能打开页面，只能证明代码跑起来了，不能证明项目成立了。

我会自己走一遍完整流程，故意输入信息不全、情绪很重、同时涉及多个部门的反馈，再去看系统怎么路由、哪里报错、最后给了什么结论。有了这个可以操作、可以出错的东西，我才有东西可以学。

这一步的重点不是让 AI 替你把项目做完，而是先做出一个能被你检查、追问和修改的东西。

这条最小业务链路，后来也成了整套 Agent 架构的骨架。

先跑通业务，再决定哪里需要Agent

04 第三步：我终于知道哪些地方该用Agent

小聆最后用了 LangGraph 做主流程编排。

你可以先把 LangGraph 理解成一块流程板，它负责把“先做什么、接着交给谁、什么时候转人工”这些步骤连接起来。

但我没有把每一个节点都包装成 Agent，整体流程是：

输入校验 → 权限检查 → Supervisor 分配任务 → 调用专业 Agent → 知识库检索 → 历史事件匹配 → 校准风险等级 → 判断是否需要人工复核 → 最终报告。

需要模型理解和判断的部分，我交给 Agent。所以我做了三个专业 Agent：品牌舆情 Agent、客服质检 Agent、运营反馈 Agent。Supervisor 像一个调度员，根据输入决定该叫谁来处理。

比如用户投诉：“客服明明答应赔偿，后来怎么又反悔了？”

客服质检 Agent 会检查承诺有没有违反赔付政策和客服 SOP，也就是标准处理流程；运营反馈 Agent 会判断这是一次沟通失误，还是流程里反复出现的问题；如果这段对话已经被发到社交平台，品牌舆情 Agent 还要继续判断它有没有扩散风险。

三个 Agent 不是为了让架构看起来高级，而是因为同一条客户声音，确实需要三种不同的专业判断。

但输入是否合法、用户有没有权限、什么风险必须转人工，这些规则是确定的。我把它们留在系统节点里，没有交给模型自由发挥。

这个取舍让我理解了预先写好步骤的 Workflow，和需要临场判断的 Agent 到底有什么区别：

不是系统里用了大模型就叫 Agent，而是有没有一部分路径需要模型在运行时判断。

确定的写进流程，不确定的交给Agent

项目跑起来以后，我继续追着 AI 问：

1. 工具调用发生在哪里，解决了什么问题？
2. 共用的事件档案，也就是 State，为什么要保存这些字段？
3. 上下文是怎么传递的，在哪里可能断掉？
4. 哪些步骤提前写死，哪些步骤由模型临时判断？
5. 哪些动作可以自动执行，哪些必须等人确认？

这时再看“状态管理”，它就不再是一句定义。小聆的 State 会保存原始输入、提取出的事实、证据链、风险等级、历史事件匹配、人工复核状态和工具调用记录。

你可以把它理解成这个事件一路处理下来，共用的一份“案情档案”。少传一个字段，后面的 Agent 就可能拿着残缺信息做判断。

有一次，小聆对同一个事件前后给出了矛盾的分析。我追到最后才发现，每次调用 Agent 时，上下文没有完整传过去，后面的节点拿到的是被截断的信息。

文档里的“上下文管理”我早就看过，但直到这个 Bug 出现，我才知道上下文断掉以后，用户最后会看到什么。

工具调用也是一样。

我给不同 Agent 配了传播扫描、客服话术合规检查、问题聚类、影响范围估算、知识库检索和历史事件匹配等工具。

每次调用不能只返回一个结果，还要记录谁调用了什么工具、权限级别、耗时、输入输出摘要，以及失败信息。否则界面上看起来是 Agent 得出了结论，出了错却没人知道它在哪一步走偏。

这也是我在项目里理解“可观测性”的方式：不是背一个技术名词，而是系统答错以后，你能不能查到它错在哪一步。

小聆会展示每一步正在调用什么Agent和工具

05 第四步：跑起来以后，还要管住它、测清楚

小聆里有一条我很早就定下来的规则：如果事件涉及赔偿、公关回应、用户联系、合规或法律判断，Agent 不能直接执行。它只能整理证据、生成建议和复核包，最终决定必须由人完成。

这就是 Human-in-the-loop，翻成人话就是：AI 可以先干活，但关键一步必须等人点头。

这道人工复核门不是为了让架构图更完整。模型给错一个分类，最多返工；赔偿和公关回应做错了，最后承担后果的是公司。

高风险事件会停在人工复核门前

权限也是同样的逻辑。

查看、检索和分析可以自动进行；创建任务、更新状态需要用户明确触发；对外回应、赔偿承诺和法律判断默认禁止。

而且权限判断由系统节点完成，不让模型自己决定自己能做什么。

做到这里，我已经能讲清楚 Agent 的工具、上下文、权限和人工复核。但项目还有一个最容易被忽略的问题：你怎么证明它真的在变好？

我为小聆准备了一组专门测试系统表现的题目，也就是评测集，我把它叫作 Xiaoling VoiceBench。

最开始有 1000 条候选评测数据，我把其中 700 条作为迭代集，300 条锁定起来做验证。其中 100 条还会进入人工校准队列，另外用 11 条核心案例检查每次修改有没有把原来正确的地方改坏。

小聆的评估与迭代模块

我还拿 DeepSeek、豆包、通义千问、Kimi 和智谱做了横向比较。不是为了选一个“最聪明”的模型，而是看同一批案例交给不同模型以后，路由、风险判断和复核建议会不会稳定。

刚开始看到评测数字的时候，我也挺兴奋。

后来重新检查数据才发现，这 1000 条公开样本大部分还是自动生成的“银标”，不是人工确认的“金标”。

如果直接把这个结果写成“上线后的真实准确率”，数字会很好看，但站不住。

所以我把口径改成“银标一致率”，并且单独建立人工校准队列。

这件事对我的触动挺大。评测不是为了给项目做一张漂亮成绩单，而是逼着你承认，系统哪些地方其实还没有被证明。

06 第五步：前端把Demo里的问题全暴露了

最后我给小聆做了一个管理端。

页面里有客户声音工作台、对话分析、事件预览、Agent 进度、人工复核、任务中心、知识库和评估模块。

我原本以为，系统在后台的处理链路跑通以后，剩下的只是把页面补齐。结果真正点起来，问题一个接一个出来了。

分析结论出现得太早，用户还没看到证据就先看到结论，凭什么信？

任务中心和人工复核的职责有重叠，用户不知道下一步该去哪。

历史记录没有持久化，刷新页面以后，刚才的分析像没发生过。

知识上传的入口做出来了，但后面的处理链路还没接通。

评测集在页面上有模块，却没有完整接进真实评测流程。

这些问题，单看后端代码很难发现。我开始一遍遍挑它的毛病：把证据放到结论前面，把同一个事件的背景和历史分析存下来，重新拆任务和复核的关系，再把没跑通的功能明确标成后续迭代，而不是假装它已经完成。

小聆也是从这个时候，才慢慢从一个能演示的 Demo，变成一个可以验证核心价值的最小产品，也就是 MVP。

代码可以让 AI 帮我实现，但先改哪一个、为什么改、哪些功能现在还不能算完成，是我做的判断。

AI可以写代码，但用户、证据、边界和评测要由人判断

07 第六步：最后才把它写进简历

项目做到这里，我才开始整理简历语言。不是“熟悉 LangGraph”，也不是“搭建过多 Agent 系统”。

我先把项目说明文档，也就是 README，以及架构说明、启动方式、页面截图和评测记录整理完整。简历上只能放一小段，但面试官继续问的时候，我得拿得出东西证明这套项目确实跑过，也知道现在还有哪些地方没完成。

我会这样介绍小聆：

小聆是我从 0 到 MVP 搭建的客户声音智能分析 Agent 项目。系统使用 LangGraph 编排 Supervisor 与三个专业 Agent，将输入校验、权限检查、风险边界和人工复核保留为确定性节点，并设计统一 State、工具调用审计、事件上下文、知识与历史案例检索，以及 VoiceBench 评测闭环。项目当前使用 SQLite 和轻量检索验证产品闭环，后续再根据数据规模升级检索方案。

翻成人话就是，我没有只做一个聊天框，而是让系统会分工、会查资料、能记住同一个事件的背景、能记录自己每一步做了什么，遇到高风险还会停下来找人确认。第一版先用轻量数据库把流程跑通，不急着为了显得高级堆复杂技术。

这段话不是越长越好，重要的是，每一个词我都能往下讲。

为什么只做三个 Agent？为什么权限不让模型判断？为什么现在先用 SQLite 和轻量检索，没有一上来就上向量数据库？为什么 1000 条数据不能直接叫准确率？前端又暴露了哪些还没做完的问题？

这些问题，我都有自己的答案。

一个项目能不能写进简历，不看页面有多漂亮，也不看技术名词有多少。看的是继续往下问时，你还有没有自己的判断。

08 最后留在简历里的是什么

我见过很多人花了三个月学 Agent，最后还是不知道自己能做什么。不一定是他们不够努力，只是他们一直在学别人整理好的答案，没有机会做自己的判断。

你不需要先把所有概念学完，再开始动手。选一个自己有感知的场景，先跑通一条最小业务链路。

遇到问题就追，发现不合理就改。工具、上下文、记忆、权限、人工复核和评测，会在这个过程中慢慢落到具体的位置上。

最后留在简历里的，不只是一套 AI 帮你生成的代码，而是你做过的那些判断。