AI Agent 项目答辩稿：毕业设计、作品集演示和面试都能用
这篇文章解决什么问题
有项目不等于会展示项目。很多同学做了 RAG、Multi-Agent、MCP、LangGraph、FastAPI，但答辩或面试时讲成了功能流水账：我做了登录、上传、问答、调用模型。这样很难体现 AI Agent 工程能力。
AI Agent 项目答辩稿的目标是提供一套可复用表达结构，让你在毕业设计、项目路演、作品集演示和求职面试中，把项目讲成“业务问题 + 架构设计 + 工程难点 + 评测结果 + 个人贡献”。
5 分钟答辩结构
| 时间 | 内容 | 目标 |
|---|---|---|
| 30 秒 | 项目一句话和背景 | 让听众知道你解决什么问题 |
| 60 秒 | 用户流程和核心功能 | 说明系统怎么被使用 |
| 90 秒 | 系统架构 | 展示工程设计能力 |
| 60 秒 | 核心难点和解决方案 | 展示技术含金量 |
| 45 秒 | 评测、指标和效果 | 证明不是主观演示 |
| 30 秒 | 总结贡献和后续计划 | 收束亮点 |
答辩不是把所有功能讲完，而是让听众记住你的核心能力。
开场模板
开场要避免“我做的是一个基于大模型的智能系统”这种空话。
模板：
大家好，我的项目是【项目名】，它面向【用户群体】，解决【具体痛点】。系统通过【RAG / Agent Workflow / Tool Calling / MCP / Evaluation】实现【核心能力】，重点不是简单调用大模型，而是把任务执行、证据检索、工具权限、过程追踪和效果评测做成一个可维护的工程系统。
示例：
大家好，我的项目是论文研究助手，面向需要阅读大量论文的学生和研发人员，解决论文资料分散、引用难追踪、跨论文对比耗时的问题。系统通过 PDF 入库、RAG 检索、多步骤 Agent Workflow 和引用评测，实现带证据的论文摘要和相关工作对比。
用户流程讲法
用户流程要按真实场景讲：
- 用户上传资料或创建任务。
- 系统解析、校验、入库并生成检索索引。
- 用户提出问题或选择任务模板。
- Agent 根据任务状态进行计划、检索、工具调用和结果校验。
- 前端展示答案、引用、状态、Trace 摘要和反馈入口。
- 用户反馈进入评测和迭代闭环。
讲用户流程时可以配合一张流程图或页面截图，但不要陷入按钮细节。
架构讲法
架构建议按层讲，不要只列框架名。
| 层 | 答辩讲法 |
|---|---|
| 前端层 | 负责任务创建、文件上传、进度展示、引用和反馈 |
| API 层 | 负责鉴权、参数校验、任务入口和状态查询 |
| Agent Runtime | 负责状态机、计划生成、工具调度和结果校验 |
| RAG 层 | 负责文档解析、chunk、embedding、检索、rerank 和引用 |
| Tool / MCP 层 | 负责外部工具 schema、权限、调用和审计 |
| 数据层 | 保存用户、任务、文档、run、step、tool_call、feedback |
| 评测层 | 通过 smoke、regression、scorecard 和人工抽检验证效果 |
| 运维层 | 通过 Docker、日志、监控、Release Gate 支撑上线 |
一句高质量表达：我的架构不是“前端 + 后端 + 模型”，而是把大模型放在可控的任务执行链路中，周围有数据、权限、工具、Trace 和评测支撑。
难点讲法
选择 2-3 个最有含金量的难点，不要讲太多。
难点一：RAG 答案可信
可以这样讲：
RAG 难点不是把文档丢进向量库，而是保证答案有证据、引用能支持结论。我的做法是把链路拆成文档解析、chunk、embedding、召回、rerank、context pack 和引用校验。每次回答保存 retrieved_chunks 和 citation，评测时检查引用是否支持答案关键句。
难点二：Agent 长任务可控
可以这样讲：
我没有让 Agent 完全自由对话，而是设计了状态机。任务从 created、queued、planning、running_tool、validating 到 completed，每一步都有结构化输入输出、超时、重试和 Trace。这样任务失败后能定位是检索、工具、模型还是状态转移问题。
难点三：工具调用安全
可以这样讲：
工具调用不是让模型直接执行函数。我把工具注册成 schema，区分 read_low、write_high、destructive 等风险等级。租户、用户、权限由系统注入，高风险动作需要审批，所有 tool_call 都记录参数摘要、结果和错误类型。
难点四：效果评测
可以这样讲：
我设计了 Evaluation Scorecard，把任务完成度、事实正确性、证据支撑、格式合法、工具调用正确性、安全性、成本和延迟拆成评分维度。每次 Prompt 或模型变更都跑 regression set，避免主观体验变好但关键能力退化。
演示顺序
现场演示建议按“最稳定、最能体现价值”的路径走：
- 展示首页或任务入口。
- 选择一个准备好的样例任务。
- 展示任务状态变化，而不是等待随机生成。
- 展示最终答案和引用。
- 展示 Trace 或工具调用记录。
- 展示评测结果或反馈闭环。
- 如果有时间，再展示异常处理或人工审批。
不要现场临时输入完全没测过的问题。答辩演示要稳定，不是冒险测试。
评测结果怎么讲
即使没有大规模用户，也可以讲离线评测。
| 指标 | 示例讲法 |
|---|---|
| 测试集 | 我构造了 30 个任务样本，覆盖普通问答、无答案、冲突证据、工具失败和注入攻击 |
| 任务完成 | 核心任务成功率达到 X，失败样本已归类 |
| 引用准确 | 检查答案关键句是否有对应证据 |
| 工具正确 | 检查工具选择和参数 schema 是否正确 |
| 安全 | Prompt Injection 和越权样本被拒绝或进入审批 |
| 成本延迟 | 统计 p50/p95 延迟和 token 成本 |
不要编造指标。没有真实指标时，可以说“当前评测集规模较小，主要用于回归验证”。诚实比夸大更可信。
60 秒面试版本
如果面试官让你快速介绍项目，可以这样讲：
我的项目是【项目名】，面向【用户】解决【痛点】。系统架构包括前端任务入口、FastAPI API、Agent Runtime、RAG 检索、MCP 工具层、数据库和评测模块。我的重点是把 Agent 做成可控工作流，而不是简单聊天：任务有状态机，工具有 schema 和权限，回答有引用和 Trace，版本有 regression evaluation。项目中最核心的难点是【难点】，我通过【方案】解决，并用【指标/测试】验证。
常见追问和回答方向
| 追问 | 回答方向 |
|---|---|
| 为什么不用普通 ChatBot？ | ChatBot 只回答文本，Agent 需要任务状态、工具、权限和执行记录 |
| RAG 答错怎么排查？ | 入库、召回、rerank、context、生成、引用逐层定位 |
| 多 Agent 有什么必要？ | 只有当任务确实需要角色分工、并行或审核时才用，多数场景状态机更重要 |
| 怎么保证安全？ | 权限过滤、工具风险等级、审批、沙箱、Prompt Injection 回归 |
| 怎么评估效果？ | Scorecard、regression set、人工抽检和线上反馈 |
| 成本怎么控制？ | 模型路由、Prompt 瘦身、缓存、top_k 控制、预算门禁 |
结束语模板
最后可以这样收尾：
总结来说，这个项目让我不只是学习了大模型 API，而是完整实践了一个 AI Agent 系统从需求、架构、RAG、工具、状态、评测到部署的工程链路。后续我会继续补充更大规模的评测集、更多 MCP 工具接入和线上反馈闭环，让系统从可演示进一步走向可运营。
常见误区
误区一：答辩只讲功能
功能只能说明系统能用，架构和难点才能证明能力。
误区二：现场随机演示
随机演示容易失败。应准备稳定样例，同时展示失败处理能力。
误区三：不讲评测
AI 项目如果没有评测，就很难证明效果。即使是小项目，也要有回归样本和评分维度。