作品集项目

Agent 岗位的简历筛选有个残酷现实：写「熟悉 LangChain、了解 RAG」的人一抓一大把，能拿出「我做了一个能跑的系统，这是 demo 视频，这是 eval 报告」的人凤毛麟角。这一页给出 6 个由浅入深的作品集项目，每个都按「1-2 周可完成、可量化、经得起追问」的标准设计。你不需要全做——做完 2-3 个并打磨好展示材料，就足够支撑一次求职。

选项目前先想清楚你要证明什么。招聘方看 Agent 方向的候选人，核心看四件事：

1. 工程闭环能力：不是调通一次 API，而是能处理失败、重试、超时、成本控制。
2. 评估意识：有没有 eval 集、成功率数字、bad case 分析——这是玩具和产品的分水岭。
3. 架构判断力：为什么用/不用某个框架，为什么是单 Agent 而不是多 Agent。
4. 表达与展示：README、demo 视频、量化结果写得清不清楚。

6 个项目恰好分别侧重这几项能力。

一、选题总览

#	项目	周期	一句话卖点	核心证明
1	个人知识库问答	1 周	完整 RAG 链路 + 检索评估	基本功
2	CLI 编码助理	1-2 周	手写最小 Agent Loop + 工具系统	原理理解
3	深度研究助理	2 周	多步搜索、报告生成、引用可溯源	长任务编排
4	浏览器自动化 Agent	2 周	订票/比价场景，真实网页操作	工具与鲁棒性
5	多 Agent 内容工厂	2 周	策划-写作-审校流水线	多 Agent 判断
6	垂直业务 Agent	2 周+	客服工单/数据分析 + 人工审批	生产思维

难度大致递增，但不是线性的：项目 2 比项目 1 难在「理解」而非「工程量」，项目 6 难在「克制」——知道哪里必须停下来交给人。

做深一个，胜过做浅六个

面试官对「我做过 6 个项目」无感，对「这个项目里最难的一个 bug 是什么、你怎么定位的」极感兴趣。建议组合：项目 2（证明懂原理）+ 项目 3 或 4（证明能做复杂系统）+ 项目 6（证明有生产意识）。其余作为备选。

二、项目一：个人知识库问答（RAG 完整链路）

一句话卖点：把自己的笔记/文档/收藏网页做成一个带引用出处的问答系统，回答不准时能说「不知道」。

这是 Agent 领域的「Hello World」，也是面试中出现频率最高的话题。做它的意义不在系统本身，而在于把 RAG 的每个环节都亲手踩一遍。

核心挑战

• Chunking 策略对效果的实际影响：固定切分、按语义切分、按文档结构切分，效果差异很大，要拿数据说话。
• 检索质量评估：构造 30-50 个「问题 → 应命中文档片段」的测试集，算 recall@k。这是大多数人跳过的步骤，恰好是最加分的一步。
• 幻觉控制：检索不到相关内容时，模型是承认还是硬编？需要在 prompt 和兜底逻辑上处理。

技术栈：Python；embedding 用 OpenAI text-embedding-3 系列或国产模型（如 BGE 系列）；向量库用 Chroma/Qdrant/pgvector 任一即可，作品集阶段不必纠结；生成模型任选主流模型。

里程碑拆解（1 周）

• 第 1-2 天：文档解析与切分（Markdown/PDF 各支持一种即可），向量化入库。
• 第 3-4 天：检索 + prompt 组装 + 生成，命令行可问答，回答附引用片段。
• 第 5 天：构造 30 条 eval 集，跑 recall@k 和「答案正确性」人工抽检，记录数字。
• 第 6-7 天：优化 bad case（调 chunk 大小、加 hybrid search 或 rerank），写 README。

可展示成果物：README 里放一张「优化前后 recall@k 对比」表格、3 个问答截图、1 个「拒答」截图（证明幻觉控制）。demo 视频 2 分钟以内。

简历写法示例：

独立开发个人知识库问答系统（RAG）：支持 Markdown/PDF 摄取与语义检索，自建 50 条评估集，通过调整 chunking 策略与引入 rerank 将检索召回率 recall@5 从 62% 提升至 89%，回答附带可溯源引用。

面试官可能追问：chunk 大小怎么定的？为什么选这个向量库？怎么评估生成质量而不只是检索质量？用户问题包含多个意图时怎么办（提示：query decomposition）？

三、项目二：CLI 编码助理（最小 Agent Loop + 工具）

一句话卖点：不依赖任何 Agent 框架，手写一个能读文件、改代码、跑命令、自我纠错的终端编码助理——200 行核心代码，证明你真的懂 Agent Loop 而不是只会调框架。

这个项目在简历上的杀伤力远超其代码量。Claude Code、Cursor 这类产品的内核就是一个 loop + 一组工具（参见 Claude Code 拆解），你手写一遍，面试时聊「ReAct」「tool use」就有了底气。

核心挑战

• 工具协议设计：tool schema 怎么写模型才不容易调错？参数校验失败时如何把错误信息喂回模型让它自我修正？
• 终止条件：模型可能无限循环调工具。需要 max turns、token 预算、重复动作检测三重保险。
• 安全边界：执行 shell 命令和写文件必须有白名单/确认机制，否则 demo 时可能当场翻车。

技术栈：Python 或 TypeScript；直接调 Anthropic/OpenAI 的原生 tool use API，不用框架；工具集 4-6 个：read_file、write_file、run_shell、list_dir、search_code。

最小 Agent Loop 骨架（Python + Anthropic SDK，2026 年现行 API 形态）：

import anthropic

client = anthropic.Anthropic()

def run_agent(task: str, max_turns: int = 20):
    messages = [{"role": "user", "content": task}]
    for turn in range(max_turns):
        resp = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            tools=TOOLS,  # 工具 schema 列表
            messages=messages,
        )
        messages.append({"role": "assistant", "content": resp.content})
        # 没有工具调用 = 任务结束
        if resp.stop_reason != "tool_use":
            return resp
        # 执行工具，把结果喂回去
        results = [execute_tool(b) for b in resp.content if b.type == "tool_use"]
        messages.append({"role": "user", "content": results})
    raise RuntimeError("超过最大轮数，强制终止")  # 三重保险之一

里程碑拆解（1-2 周）

• 第 1-2 天：最小 loop 跑通，只支持 read_file + 对话。
• 第 3-5 天：补齐工具集，加入危险操作确认（run_shell 前打印命令等 y/n）。
• 第 6-7 天：自我纠错链路——编译/测试失败后模型读报错、改代码、重跑，录一段「修 bug 全过程」视频。
• 第 8-10 天（可选）：加一个 eval：找 10 个真实小任务（如「给这个函数补单测」），统计一次通过率。

可展示成果物：一段 3 分钟的终端录屏（模型自己读代码、改代码、跑测试、修报错），README 里画一张 loop 流程图并标注每处失败处理。强调「零框架」。

简历写法示例：

从零实现 CLI 编码助理（不依赖 Agent 框架）：手写 Agent Loop 与 tool use 协议，支持文件读写/shell 执行等 6 种工具，具备危险操作确认与循环熔断机制；在 10 个真实编码任务上首试成功率 70%，失败案例中 80% 可经自我纠错恢复。

面试官可能追问：和 Claude Code 比差在哪（提示：context 压缩、子 Agent、权限系统，可链接到你对 context engineering 的理解）？模型调错工具参数时你的错误信息怎么设计的？怎么防止它删掉重要文件？

四、项目三：深度研究助理（多步搜索 + 报告生成）

一句话卖点：输入一个问题，自动拆解子问题、多轮搜索、交叉验证来源，输出一篇带逐条引用的研究报告——开源复刻 Manus/Deep Research 的核心体验。

2025 年以来 Deep Research 类产品（OpenAI、Gemini、Perplexity，以及 Manus）成了 Agent 最出圈的场景，开源侧也有 GPT Researcher（约 2.8 万 star）和 LangChain 的 open_deep_research（约 1.2 万 star）两个成熟参照。自己做一遍，正好覆盖「规划、工具调用、长文写作、引用溯源」四个高频面试点。

核心挑战

• 任务分解与迭代：第一轮搜索结果会暴露新的子问题，规划不能是一次性的。可以参考 规划模式 里的 plan-and-execute 思路。
• 信息去重与冲突处理：不同来源说法矛盾时，报告应该呈现分歧而不是强行选一个。
• 引用可溯源：每个论断挂到具体 URL + 抓取片段，允许读者点击核对。这是「研究报告」和「模型瞎编的长文」的唯一区别。
• 成本控制：一次深度研究可能烧掉几十万 token，要有搜索轮数/来源数上限（参见 成本优化）。

技术栈：搜索用 Tavily/Brave Search API（都有免费额度）；编排可以用 LangGraph（顺便积累框架经验）或纯 Python；报告生成用长上下文模型；引用管理自己实现（URL + 抓取时间 + 原文片段）。

里程碑拆解（2 周）

• 第 1-2 天：单轮版——问题 → 搜索 → 总结，带引用，验证端到端链路。
• 第 3-5 天：加入 planner：问题分解为子问题列表，逐个研究，最后汇总成结构化报告（摘要/正文/引用列表）。
• 第 6-8 天：加入反思循环：每轮搜索后判断「信息是否足够」，不足则生成追问查询，最多 N 轮。
• 第 9-11 天：引用溯源与冲突呈现；加 token 预算护栏。
• 第 12-14 天：选 5 个真实问题跑完整报告，人工核对引用准确率，写 README 对比「直接问模型」与「研究流程」的答案质量差。

可展示成果物：2-3 份完整研究报告 PDF/Markdown（挑有信息增量的问题，如「2026 年向量数据库选型对比」），一张 agent 工作流架构图，引用准确率统计（如「抽查 60 条引用，58 条与原文一致」）。

简历写法示例：

开发深度研究 Agent：基于 plan-and-execute 架构实现问题分解、迭代搜索与反思循环，生成带逐条引用的研究报告；单次任务平均调用搜索 15 次、消耗约 8 万 token，引用准确率 96%（60 条人工抽检）。

面试官可能追问：怎么判断「研究做完了」？搜索结果里的 SEO 垃圾/AI 生成内容怎么过滤？和直接用 Perplexity 比你的差异化在哪？如果来源互相矛盾你的报告怎么写？

五、项目四：浏览器自动化 Agent（订票/比价场景）

一句话卖点：给一句自然语言指令（「帮我比价三个平台上这本书的价格」），Agent 自己打开浏览器、导航、填表、提取结构化结果——直面真实网页的脏乱差。

浏览器操作是 Agent 工具链里最难的一环：页面是给人看的不是给模型看的，弹窗、验证码、动态加载、A/B 改版随时会让流程崩掉。做成这个项目，证明你能处理「真实世界的脏」。2026 年的主流路径已经很清晰：直接用 browser-use（约 10 万 star 的开源库，Python 生态的事实标准）或 Stagehand（Browserbase 出品，TypeScript），再或者通过 Playwright MCP 把浏览器能力接给你自己的 Agent。

核心挑战

• 感知表示：把 DOM 压成模型能消化的形式（可访问性树、交互元素编号），原始 HTML 直接喂进去会爆 context 且效果差。
• 脆弱性与恢复：元素找不到、页面改版、网络超时。每一步都要有重试和「换条路走」的 fallback。
• 反爬与合规：目标站的风控、登录态、操作频率限制。作品集阶段只碰允许自动化的公开页面，别在 README 里展示绕过验证码。
• 不可做的事要坚决不做：真实支付、真实下单一律停在最后一步，让人来确认。

技术栈：browser-use（Python）或 Stagehand（TS）二选一，别自己从零写 DOM 解析；底层都是 Playwright；模型需要较强的视觉/推理能力（截图理解比纯 DOM 更稳但更贵）。

用户指令: "在 A、B 两个平台查 X 商品价格并给出建议"
        │
        ▼
┌─────────────┐   失败重试/换选择器   ┌──────────────┐
│  Agent Loop  │ ◄────────────────── │  浏览器环境    │
│ (规划+反思)   │ ── 点击/输入/滚动 ──► │ (Playwright)  │
└──────┬──────┘                      └──────────────┘
       │ 每个站点完成后产出结构化记录
       ▼
┌─────────────┐
│ 结果汇总+比价  │ ──► JSON/Markdown 报告
└─────────────┘

里程碑拆解（2 周）

• 第 1-3 天：跑通 browser-use 官方示例，换成自己的目标场景，完成单站点流程。
• 第 4-6 天：多站点任务编排，统一输出结构化结果（JSON schema 约束）。
• 第 7-9 天：加固——重试策略、超时、页面改版后的 graceful degradation、失败截图留档。
• 第 10-12 天：成功率统计（同一任务跑 20 次，记录成功率与失败原因分布），这是最值钱的数字。
• 第 13-14 天：录 demo、写 README，明确写清合规边界。

可展示成果物：分屏 demo 视频（左边 Agent 思考日志，右边浏览器实时画面），成功率统计表，失败案例截图集（「我是怎么处理这 5 类失败的」）。

简历写法示例：

基于 browser-use 构建跨平台比价 Agent：自然语言指令驱动浏览器完成搜索、筛选与信息提取，输出结构化比价报告；通过重试与降级策略将任务成功率从初版 45% 提升至 85%（20 次重复实验），平均单次任务耗时 90 秒。

面试官可能追问：成功率怎么测的、样本量多少？页面改版了怎么办（有没有自愈机制）？为什么选 browser-use 而不是自己写 Playwright 脚本（答案的关键：任务有不确定性时才需要 Agent，固定流程写脚本更可靠——这个判断本身就是加分项）？遇到登录墙/验证码怎么处理？

六、项目五：多 Agent 内容工厂（策划-写作-审校流水线）

一句话卖点：三个各司其职的 Agent——策划（选题与大纲）、写手（成稿）、审校（事实核查与风格把关）——组成内容生产流水线，人可以只审大纲和终稿。

这个项目的目的不是「多 Agent 很酷」，恰恰相反：做完之后你应该能清楚说出什么时候多 Agent 是过度设计。单 Agent 按顺序干三件事也能跑，多 Agent 的价值在于隔离 context（写手不需要看到策划的搜索垃圾）、独立迭代（审校标准可以单独调）、并行（多个选题同时写）。能把这笔账算清楚，比流水线本身更打动面试官。关于编排模式的系统讨论见 多 Agent 架构。

核心挑战

• 交接产物设计：Agent 之间传的不是聊天记录而是结构化产物（大纲 JSON、稿件、修改意见清单），schema 要先定死。
• 审校 Agent 的可信度：让它「事实核查」需要给它搜索工具，否则只是换个模型再编一遍。
• 拒绝无限互改：写手 ↔ 审校的修改循环必须有轮数上限和人来终裁，否则两个 Agent 能互相改到天荒地老。

技术栈：编排用 LangGraph（2026 年仍是主流，supervisor/流水线模式都有成熟写法）或 CrewAI（上手更快，见 框架选型）；写作模型选长文能力强的；审校 Agent 配搜索工具。

里程碑拆解（2 周）

• 第 1-3 天：单 Agent 顺序版跑通（策划→写作→审校一把梭），作为 baseline。
• 第 4-7 天：拆成三个 Agent，定义交接 schema，跑通流水线。
• 第 8-10 天：加入人工审批点（大纲确认、终稿确认），以及修改轮数上限。
• 第 11-14 天：对比实验——同一批选题，单 Agent 版 vs 多 Agent 版，人工盲评质量 + 对比 token 成本，把结论写进 README。这个对比就是你的核心洞察。

可展示成果物：一张流水线架构图，2-3 篇完整产出（含大纲、初稿、审校意见、终稿的全过程留档），单 Agent vs 多 Agent 的质量/成本对比表。

简历写法示例：

设计多 Agent 内容生产流水线（策划/写作/审校三角分工，LangGraph 编排）：定义结构化交接协议与人工审批节点，相比单 Agent 方案盲评质量分提升 22%、单篇成本增加 35%，并基于实验结论给出多 Agent 适用边界的分析文档。

注意这条写法故意把「成本增加 35%」也写进去了——敢写 trade-off 的简历比全是「提升」的简历可信得多。

面试官可能追问：为什么不用一个 Agent 加三段 prompt？审校 Agent 提出反对意见但写手不认怎么办？（提示：仲裁机制）并行做了吗，瓶颈在哪？如果让你上生产，哪个环节最先换掉？

七、项目六：垂直业务 Agent（客服工单/数据分析，含人工审批）

一句话卖点：选一个真实业务场景（客服工单分类与草拟回复、或自然语言查数），做到「能 demo 给业务方看」的程度，并且在高风险动作前设置人工审批闸。

这是 6 个项目里唯一一个考察「生产思维」多于「算法技巧」的。企业级 Agent 的核心矛盾是自主性与可控性：全自动没人敢用，全人工又没有价值。你的设计——哪些动作自动执行、哪些必须人来批、审批界面长什么样、审批记录怎么留痕——就是这个项目的灵魂。系统性的讨论见 人工介入 与 Agent 安全。

核心挑战

• 置信度分级：高置信度自动执行，低置信度转人工。阈值怎么定？用 eval 集校准，别拍脑袋。
• 审批体验：审批人看到的不该是原始 trace，而是「Agent 想做什么、依据是什么、一键批准/修改/驳回」。
• 可观测与追责：每次自动执行和人工干预都要留痕（输入、输出、决策理由、操作人），参见 可观测性。

技术栈：以客服工单为例——编排用 LangGraph（其 interrupt() + checkpointer 机制就是为「暂停等人审批再恢复」设计的）；工单数据自己造 100-200 条模拟数据；前端一个极简审批页面（Streamlit/Gradio 就够，别在前端上烧钱）。

里程碑拆解（2 周+）

• 第 1-3 天：造数据 + 基线：工单分类（意图识别）+ 检索历史相似工单 + 草拟回复。
• 第 4-6 天：eval 集校准：测分类准确率和回复可用率，定置信度阈值。
• 第 7-9 天：接入 interrupt() 审批流：低风险（如自动打标签）直接执行，高风险（如给客户发回复、退款）挂起等人批。
• 第 10-12 天：审批页面 + 全程留痕日志。
• 第 13-14 天：写一份「自动化率 vs 风险」分析：多少工单能全自动、拦截了多少个 Agent 的错误决策。

可展示成果物：审批流的 demo 视频（重点拍「Agent 犯错被审批拦下」的一幕，这比 100 个成功案例更能体现你的理解），自动化率/拦截率数字，一页纸的权限设计文档。

简历写法示例：

构建客服工单 Agent（LangGraph + 人工审批流）：实现意图分类、相似工单检索与回复草拟，基于 150 条 eval 集校准置信度阈值，实现 68% 工单全自动处理；高风险动作经 interrupt 挂起人工审批，试运行期间拦截 Agent 错误决策 12 次，全程操作留痕可审计。

面试官可能追问：阈值怎么定的，误拦和漏放怎么权衡？审批人改了他的决策，这些反馈数据怎么回流改进系统？（提示：这是 RLHF/在线学习的入口）如果 Agent 和用户串通骗审批怎么办？这套东西搬到金融/医疗场景要改什么？

八、把项目变成 offer：展示材料的硬要求

项目做完只值一半价钱，另一半在展示。几条硬标准：

1. README 是门面。结构：一句话说清这是什么 → 30 秒 demo 动图/视频 → 架构图 → 怎么跑起来 → 关键设计决策与权衡 → 评估数字 → 局限性。局限性必须写，不写等于告诉面试官你没想过。
2. 每个项目至少一个量化数字。成功率、准确率、成本、延迟，任选，但必须有，且必须说清测量方法。「效果很好」是废话，「20 次重复实验成功率 85%」是证据。
3. demo 视频控制在 3 分钟内，展示完整闭环（输入 → 过程 → 结果），最好包含一次失败与恢复。
4. 代码要能跑。README 里的安装步骤找台干净机器实测一遍；依赖 pin 版本；API key 走环境变量。
5. 简历与面试的衔接：简历上每个项目写 2-3 条 bullet，每条 = 做了什么 + 怎么做的 + 量化结果；面试追问的答案在项目里真做过，别写自己答不上来的数字。关于简历整体写法见 简历分析，追问的系统性准备见 面试题库。

三个最常见的翻车点

• 只贴 GitHub 链接，没有任何数字和 demo——面试官不会 clone 你的仓库。
• demo 只录成功案例——稍有经验的面试官会默认你的成功率是 100% 减你藏起来的部分。
• 简历写「精通 LangGraph」但答不上 interrupt() 的恢复机制——用过和精通的差距，一次追问就露馅。

最后一个建议：所有项目共用一个「工程底座」——统一的 eval 脚本模板、trace 记录格式、README 模板。到第三个项目时你会发现效率翻倍，而这个底座本身就是可以向面试官展示的工程素养。如果你想先跑通一个最小闭环再挑项目，可以从 动手造一个 Agent 开始；想看别人怎么把单个项目讲成作品集级别的复盘，常见陷阱 里有不少反面教材。

参考资料

• browser-use/browser-use (GitHub) —— 浏览器自动化 Agent 的主流开源库，项目四的首选底座。
• langchain-ai/open_deep_research (GitHub) —— LangChain 出品的开源深度研究 Agent，项目三的参照实现。
• assafelovic/gpt-researcher (GitHub) —— 另一个成熟的深度研究开源项目，适合拆解其多步搜索与引用设计。
• Browser Agents in 2026: Browser Use vs Stagehand vs Skyvern vs Playwright MCP —— 2026 年浏览器 Agent 工具链对比，支撑项目四的技术选型。
• LangGraph 官网 —— 项目五、六的编排框架，含 human-in-the-loop 与持久化状态设计说明。
• AI Agent Frameworks Compared (2026) —— 2026 年 Agent 框架格局综述，用于确认各框架现状。
• LangGraph Human-in-the-Loop (2026): interrupt() 教程 —— 项目六审批流的 API 级参考。