如果你做过 AI Agent 项目，你大概率遇到过这种尴尬：
- Demo 在你电脑上跑得挺好，但换个输入就开始胡说。
- 面试官问“怎么评估？”你只能说“我感觉还行”。
- 面试官问“怎么保证不越权、不乱调工具？”你没想过。
这不是你不努力，而是多数 AI 教程把你带到了“能跑起来”就收工的层级。但面试官在看的是：你能不能把不确定的 LLM 变成可交付系统。
这篇文章只回答一个问题：
一个 AI Agent 项目怎样做，才能让面试官一眼觉得“有含金量”？
核心结论先给：含金量不是功能多，而是闭环完整。
一、先拆掉误区：什么样的 Agent 项目“含金量很低”？
下面三种项目在 2026 年已经很难加分了（不是没价值，而是同质化严重）：
1) “聊天 UI + 调模型 API”
- 特征：前端体验做得很漂亮，但后端几乎就是透传。
- 面试官判断：这是接入能力，不是 Agent 工程能力。
2) “照着框架文档把 Agent 跑起来”
- 特征：能讲 LangChain、能贴一堆代码，但解释不了“为什么这么选”。
- 面试官判断：组件调用者，不是系统设计者。
3) “功能堆得很满，但没有评估与观测”
- 特征：有 RAG、有工具、有 memory，但没有指标、没有 trace、无法回放。
- 面试官判断：你无法证明效果，也无法迭代。
残酷但真实：Agent 项目真正的难点，绝大多数不在模型调用，而在“系统工程”。
二、含金量判定标准：面试官用什么尺度衡量？
给你一套可自测的“含金量四象限”。只要你能把任一象限做扎实，项目就很难被当成玩具。
维度 A：任务闭环（Task Loop）
你是否能讲清一次 run：
- 输入是什么？（用户意图 + 约束）
- 状态怎么流转？（结构化状态、阶段）
- 失败怎么兜底？（降级、重试、重规划）
- 成功怎么判定？（成功条件、校验器）
如果你没有一个清晰的 run 叙事，你的项目很难显得“工程化”。
维度 B：可观测与可评估（Observability & Eval）
至少要做到：
- 每次 run 有 trace（检索、规划、工具、输出）
- 有一套小型 eval 集（20-100 条）能离线回放
- 能报出关键指标：完成率、P95 延迟、平均 LLM 调用次数、工具失败率、引用证据比例
维度 C：可靠性与成本（Reliability & Cost）
你是否处理过：
- tool 超时/限流/5xx 的重试策略
- 幂等（避免重复下单、重复写库）
- 并发与隔离（多用户串话、资源抢占）
- token 成本下降（摘要、检索、缓存、模型分层）
维度 D：安全与权限（Security & Permissions）
你是否考虑过：
- prompt 注入与越权工具调用
- 工具白名单 + 最小权限原则
- 敏感信息脱敏与最小暴露（只给模型必须信息）
如果你能把 D 讲清楚，面试官通常会非常认可：这是“线上系统意识”。
延伸阅读：
三、选型：三类最容易做出含金量的 Agent 项目
你不需要做“万能 Agent”，更推荐做“任务型 Agent”。下面三类选题最容易体现工程能力。
1) PDF / 文档 Agent（检索 + 结构化输出 + 工具）
为什么含金量高：
- RAG 质量可评估（引用证据、准确率）
- 结构化输出天然适配 schema 校验
- 工具链清晰（解析、抽取、生成）
最低可行目标（MVP）：
- 用户上传 PDF
- Agent 提取关键信息生成结构化 JSON（schema 校验）
- 可选：生成一份报告/合同摘要/清单
含金量升级点：
- 引用证据片段（页码/段落）
- 失败回放：哪些问题答错、为什么（切块/召回/精排/提示词）
2) 会议纪要 / 工单 Agent（记忆 + 状态机 + 评估）
为什么含金量高：
- 多轮对话与状态管理是核心难点
- “跑偏检测”和“成功条件”能显得很工程
最低可行目标：
- 多轮收集信息
- 输出结构化纪要 + TODO + 风险点
含金量升级点：
- 工作记忆（结构化状态）可校验
- 支持“纠错回路”（用户改一处，系统重算相关输出）
3) 客服 / 业务助手 Agent（权限 + 工具调度 + 成本）
为什么含金量高：
- 真实世界工具调用复杂：查询、写入、权限、审计
- 成本与稳定性问题更突出
最低可行目标：
- 用自然语言查询业务数据（只读工具）
- 输出引用证据 + 建议下一步
含金量升级点：
- 权限模型：不同角色看到不同字段
- 幂等与审计：写操作必须可追踪
四、把项目做“像系统”：一个可复用的架构骨架
不管你选哪类项目，建议把工程骨架搭成下面这个结构。你不一定要全部实现，但必须能解释每层存在的意义。
4.1 六个模块（最小工程分层）
ContextBuilder：把输入 + 状态 + 证据组合成上下文MemoryStore：短期对话 + 摘要 + 结构化状态Planner：生成结构化计划（步骤、依赖、成功条件、stop condition）Executor：执行计划（tool 调度：timeout/retry/幂等/并发控制）Validator：校验输出（schema/业务规则/引用证据）RunLogger：trace + metrics（可回放）
如果你愿意更像生产系统，再加一个：
PolicyEngine：权限、工具白名单、敏感信息脱敏
4.2 你必须设计“状态机”
面试官最怕的是：项目描述听起来像一团糊。
把 run 画成状态机能瞬间提升可信度：
IDLE
-> BUILD_CONTEXT
-> PLAN
-> EXECUTE_STEP (loop)
-> VALIDATE
-> OUTPUT
-> RECORD
-> DONE
(on error) -> RECOVER or DEGRADE
你不需要写复杂的状态机库，但至少要定义：
- 每个状态的输入/输出
- 失败时进入哪个状态
- 最大步数/最大时间（stop condition）
五、让它“可证明”：最小评估体系怎么做？
没有评估，所有“含金量”都只能靠嘴。
5.1 先做离线 eval：20 条就够了
你可以从 3 类用例起步：
- 正常用例：能正确完成
- 噪声用例：检索中混入干扰文档
- 失败注入：工具超时/429/参数缺失
每条用例定义：输入、期望（成功条件）、可接受的降级输出。
5.2 至少记录这 8 个字段（面试强加分）
run_id/session_idmodel/temperature/prompt_versionllm_calls/token_in/token_outtool_calls（每个 tool 的 latency、error、retry 次数）citations（引用证据）result_status（success/degrade/fail + reason）
5.3 你应该能回答三个“可量化”问题
- 改了提示词/检索/规划后，完成率变化是多少？
- P95 延迟是否超标？瓶颈在哪一步？
- 成本怎么降？降了多少？
延伸阅读：
六、面试叙事模板：一页讲清“为什么这个项目有含金量”
你可以用下面结构写简历/面试讲述。核心是把“技术栈”换成“系统设计与证据”。
6.1 一句话定义项目
我做了一个任务型 Agent：在约束条件下规划并调用工具完成任务，支持可回放的 trace 与离线 eval，能在工具失败时降级并给出解释。
6.2 讲一次 run（不要讲组件名）
- 输入：用户目标 + 约束
- 上下文：结构化状态 + RAG 证据
- 规划：结构化计划（含成功条件、stop condition）
- 执行：工具调度（timeout/retry/幂等/并发）
- 校验：schema + 业务规则 + 引用证据
- 记录：trace + 指标 + 回放
6.3 讲一个最大坑（并给出指标证明）
例如：
- 坑：检索命中不稳定导致幻觉
- 解决：切块策略 + 引用硬约束 + 拒答策略
- 证据：引用率从 x% 提升到 y%，错误率下降 z%
如果你能给出 eval 集的数字，即便是自建数据，也比“感觉还行”强太多。
七、从 Demo 升级到“可上线系统”的检查清单
这是你把项目从“能跑”升级到“可交付”的最短路径。
必做（最小含金量）
- 结构化输出 + schema 校验
- RAG 引用证据（或明确拒答）
- run 级 trace（至少能回放）
- 20-100 条离线 eval 集
加分（工程能力）
- tool timeout/retry/幂等
- stop condition + 跑偏检测 + 重规划上限
- 多用户隔离 + 并发控制
高分（系统意识）
- 权限模型 + 工具白名单
- 成本模型（每次 run 成本估算与优化）
- A/B 或 prompt versioning
如果你愿意继续把“提示词工程”做成工程闭环，下一篇会把 Agent Prompt 的结构、测试与版本化讲透：
