AI Agent 作品集 Case Study 模板：把项目讲成可证明能力

这篇文章解决什么问题

很多 AI Agent 项目写在简历或博客里时，只剩下“用了 LangGraph、RAG、FastAPI、MCP”。这类描述很难证明能力，因为面试官看不出业务问题、系统设计、工程难点、评测结果和你的贡献。

AI Agent 作品集 Case Study 的目标是把一个项目讲成可验证的能力证据：为什么做、怎么设计、解决了什么难点、用什么指标证明有效、失败后如何迭代。

一篇 Case Study 应该回答的问题

问题	面试官真正想知道
为什么做这个项目	你是否理解业务场景，而不是为了堆技术
用户是谁	你是否能定义真实使用者和任务
系统怎么设计	你是否具备架构抽象能力
难点在哪里	你是否遇到并解决过工程问题
如何评测	你是否能证明效果而不是主观自夸
如何上线	你是否考虑部署、监控、成本和安全
你负责什么	你是否有明确贡献边界

作品集不是项目说明书，而是能力证明材料。

推荐结构

一篇完整的 Agent Case Study 可以按以下结构写：

1. 项目一句话介绍
2. 背景和用户痛点
3. 目标和非目标
4. 用户流程
5. 系统架构
6. 数据模型
7. Agent Workflow
8. RAG / Tool / MCP 设计
9. 评测和指标
10. 安全和权限
11. 部署和运维
12. 难点与取舍
13. 结果与复盘
14. 面试讲法

如果篇幅有限，至少保留背景、架构、难点、评测和贡献五部分。

一句话介绍模板

好的项目介绍应该包含用户、任务、技术路径和结果。

模板：

面向【用户/团队】的【场景】Agent 系统，支持【核心任务】，通过【RAG/工具/MCP/状态机/评测】实现【可验证结果】。

示例：

• 面向研发团队的代码变更分析 Agent，支持 PR 风险总结、测试建议和发布说明生成，通过仓库检索、工具调用和对话回归测试提升代码审查效率。
• 面向运营团队的工单辅助 Agent，支持知识库检索、答案生成、人工接管和反馈回流，通过 RAG 引用、Trace 和评测集降低重复工单处理成本。
• 面向个人研究者的论文阅读 Agent，支持论文入库、摘要、相关工作对比和想法生成，通过文档解析、向量检索和多步骤工作流沉淀研究记录。

背景和痛点

不要一上来讲框架，先讲问题。

写法	示例
低质量	我做了一个 RAG Agent 项目
高质量	论文阅读时资料分散、引用难追踪、跨论文对比耗时，因此我设计了一个能把 PDF 入库、检索证据、生成摘要并保留引用链的研究助手

背景部分要包含：

• 谁在什么场景下遇到问题。
• 现有方式为什么低效或不可靠。
• 为什么 Agent / RAG / Tool Calling 适合解决。
• 项目边界是什么，不解决什么。

目标和非目标

目标要可验证，非目标要体现边界意识。

类型	示例
目标	支持上传 PDF 后生成带引用的结构化摘要
目标	支持用户对答案反馈，并转成评测样本
目标	记录每次 Agent 执行 Trace，支持失败排查
非目标	不做全自动论文写作
非目标	不绕过版权和权限访问外部数据库
非目标	不承诺模型回答 100% 正确

面试官喜欢看到非目标，因为这说明你不是盲目扩大范围。

用户流程

用流程说明系统如何被使用，而不是只画技术架构。

示例流程：

1. 用户上传文档或创建任务。
2. 系统校验文件、解析内容、生成 chunk 和 metadata。
3. 用户提出问题或选择分析模板。
4. Agent 检索证据、生成计划、调用工具。
5. 系统展示答案、引用、置信度和 Trace 摘要。
6. 用户反馈正确、错误或需要人工修正。
7. 反馈进入评测集和迭代队列。

这条流程能自然引出后端、RAG、状态机、前端和评测设计。

架构说明模板

架构部分可以按层讲：

层	作用
Frontend	任务创建、文件上传、进度展示、引用和反馈
API	鉴权、请求校验、任务入口、状态查询
Agent Runtime	计划、状态机、工具调度、结果校验
RAG	文档解析、chunk、embedding、检索、rerank、引用
Tool / MCP	外部工具接入、schema、权限、审计
Storage	用户、任务、文档、run、step、tool_call、feedback
Evaluation	smoke、regression、judge、人工抽检
Ops	Docker、日志、监控、runbook、release gate

讲架构时不要只报技术名词，要讲每层解决什么问题。

Agent Workflow 怎么写

Agent Workflow 是作品集的亮点。建议写清楚：

• 任务状态：created、queued、planning、running、validating、completed、failed。
• 输入输出：每一步的 schema 和证据。
• 工具权限：哪些工具自动执行，哪些需要审批。
• 失败恢复：超时、无证据、工具失败、低置信度怎么处理。
• Trace：run_id、step_id、tool_call_id 如何记录。

示例表达：

我没有把 Agent 做成自由聊天，而是设计了状态机工作流。任务创建后进入队列，Worker 按状态推进计划生成、检索、工具调用和结果校验。每一步都有结构化输入输出，并记录 Trace。高风险工具调用进入人工审批，失败后按错误分类决定重试、降级或转人工。

评测和指标怎么写

作品集一定要有指标，即使是个人项目，也可以设计离线评测和演示指标。

指标	示例
Task Success	20 个测试任务中完成 17 个，部分完成 2 个
Citation Accuracy	引用是否支持答案关键句
Retrieval Recall	关键文档是否进入 top_k
Format Validity	JSON / Markdown / 表格输出是否符合 schema
Tool Correctness	工具选择和参数是否正确
Latency	p50、p95 任务耗时
Cost	每任务 token 和模型成本
Safety	Prompt Injection、越权、危险工具是否被拦截

不要夸大结果。可以诚实写“当前样本量较小，主要用于回归和展示，但评测链路已经具备扩展能力”。

难点与取舍

难点要讲工程细节，不要只说“多 Agent 很复杂”。

难点	更好的讲法
RAG 效果差	我把问题拆成入库、召回、rerank、context pack 和生成五层排查
工具调用不稳	我通过 tool schema、参数校验、错误分类和重试策略提升稳定性
长任务失败	我引入状态机、幂等键和断点续跑，避免从头重跑
成本高	我做 Prompt 瘦身、模型路由、缓存和批处理
不安全	我设计工具风险等级、审批、沙箱和 Prompt Injection 回归样本

每个难点最好对应一个方案和一个验证方式。

贡献边界怎么写

如果是个人项目，可以写“独立负责”；如果是团队项目，要写清楚你负责的模块。

模板：

我主要负责【模块】，包括【设计/实现/测试/部署】。在这个过程中解决了【难点】，通过【指标/测试/评测】验证，最终产出【功能/文档/演示/上线结果】。

示例：

我主要负责 Agent Runtime 和评测链路，包括任务状态机、工具调用记录、失败分类和 regression set。通过 30 个离线样本验证核心流程，并把 5 个历史失败样本加入回归测试，避免 Prompt 修改导致能力退化。

面试用 60 秒版本

60 秒介绍可以按下面顺序：

1. 一句话说明项目和用户。
2. 说明核心业务流程。
3. 讲架构中的 2-3 个关键模块。
4. 讲一个最有含金量的难点。
5. 用指标或评测说明结果。

模板：

这个项目是面向【用户】的【Agent 系统】，解决【痛点】。整体架构分为前端任务入口、FastAPI 后端、Agent Runtime、RAG 检索、工具/MCP 接入和 Evaluation。我的重点不是只调模型，而是把任务执行做成状态机，记录 run、step、tool_call 和反馈。难点是【难点】，我通过【方案】解决，并用【评测/指标】验证。这个项目能证明我具备 Agent 工程化、RAG、工具治理、评测和上线意识。

博客页面检查清单

发布 Case Study 前检查：

• 是否有一句话介绍。
• 是否有用户和痛点。
• 是否有架构分层。
• 是否有流程或状态机。
• 是否有数据模型或 Trace 设计。
• 是否有 RAG / Tool / MCP 具体方案。
• 是否有评测指标。
• 是否有安全和权限设计。
• 是否有难点与取舍。
• 是否有面试表达版本。

常见误区

误区一：把作品集写成技术栈列表

技术栈只能说明你接触过工具，不能证明你能解决问题。Case Study 要围绕业务、架构、难点和指标展开。

误区二：只展示成功路径

真实项目一定有失败和取舍。写清楚失败如何排查、如何修复、如何进入回归测试，反而更能证明工程能力。

误区三：没有指标

没有指标，项目就只能靠主观描述。即使是个人项目，也应该设计小规模评测集、演示任务和质量评分。