面试官让你现场设计一个 Agent，别急着画架构图。真正的考点在于你是否能判断需求是否适合用 Agent、如何设计决策与执行层、如何规划上线风险，以及上线后如何用指标和 trace 持续优化。本文拆解四段面试应答框架，附场景示例与话术，助你从容应对。

面试进行到一半，面试官把笔递给你，说：「你现在设计一个 Agent 吧，什么场景你自己定。」这时候大多数人的第一反应，是拿起笔开始画框图——用户输入在左边，中间一个大模型，右边接几个工具，下面画个数据库，箭头一连，讲一遍数据怎么流。

画得挺完整，但面试官的表情通常不会变。因为这道题考的根本不是你会不会画架构图。

其实面试官真正想看的是三件事——你判断场景的能力、你设计系统的能力、以及你有没有想过上线之后会出什么事。这篇文章我想做的，是把这四段展开成你在白板前可以直接用的东西：每一段说什么、判据是什么、举什么例子、怎么开口

一、先判断这需求配不配做 Agent

「判断需求是否适合做 agent」，三个判据：是否需要动态决策、是否有大量非结构化信息、固定 workflow 是否能解决。我把这三条按实际好用的顺序重排一下：

判据一：固定 workflow 能不能解决？（这是反向判据，也是最该先问的）

如果一个需求，你能用「第一步做 A，第二步做 B，遇到 C 就走分支」把它写完，那它就不该上 Agent。

写成流程图能跑通的东西，用 Agent 做只会更慢、更贵、更不稳定。

判据二：过程中需不需要动态决策？

关键在「动态」两个字。不是「有分支」就叫动态——if 金额 > 5000 then 走总监审批 这是分支，不是决策。

真正的动态决策是：下一步做什么，取决于上一步的结果，而且这个结果事先无法穷举。

判据三：输入里有没有大量非结构化信息？

如果输入是表单、是字段、是选项，那是传统系统的活。如果输入是一段用户随口写的话、一份 PDF、一封邮件、一段对话记录——大模型才有用武之地。

【假设场景】两个需求，一个该上，一个不该

假设你要做一个报销审批的功能。

规则很清楚：金额低于 500 直属领导批，500 到 5000 部门负责人批，5000 以上走财务复核；发票需要验真伪，超期的自动驳回。

这个需求三条判据全部不满足——固定 workflow 能写完、分支是穷举得完的、输入是结构化字段。用 Agent 做是杀鸡用牛刀，而且这把牛刀还会偶尔砍偏。

再假设你要做一个客户投诉的处理功能。

进来的是用户在 App 里写的一段话，可能夹着订单号、可能没有；可能是物流问题、可能是质量问题、也可能两个都有还带着情绪。系统需要先看懂他到底在投诉什么，再决定是查订单、查物流、还是调历史客服记录，查完了才知道下一步该补偿还是该转人工。

这个就配得上 Agent——输入非结构化、下一步依赖上一步的结果。

面试话术示范

「我先判断一下这个需求适不适合做 Agent。我会问三个问题：这件事能不能用一张固定的流程图写完？过程中的下一步，是不是要看上一步的结果才知道？输入是结构化的字段，还是自然语言、文档这类非结构化信息？

如果第一个问题的答案是『能』，我就不会上 Agent——固定 workflow 更快更稳更便宜。我今天选的这个场景之所以适合，是因为……」

为什么这一段最加分： 它证明你不是拿到需求就开干的人。能说出「这个不该做 Agent」，比会设计十个 Agent 更能体现判断力。

二、设计系统，重点在决策和执行

这部分有五个环节：任务规划、决策路由、工具执行、评测、反馈优化，重点在决策和执行。

五个环节各自在干什么：

规划和优化这两环，很多团队初期是可以先简化的——规划可以先写死一套模板，优化可以先靠人工看日志。但决策和执行不能简化，因为它们是唯一会真的动到线上数据的部分。

决策错了，方向就错了；执行错了，用户就受损了。前者浪费成本，后者是事故。

【假设场景】一个合同审查 Agent，五个环节各是什么

假设你要做一个帮法务初审合同的 Agent。

• 任务规划：拿到一份 PDF 合同，拆成「提取关键条款 → 逐条比对内部红线 → 标出风险点 → 生成审查意见」四步
• 决策路由：读到一条付款条款，它得决定——这条是走标准模板比对，还是因为条款写得含糊需要调历史合同库找类似案例？
• 工具执行：调 PDF 解析、调红线规则库、调历史合同检索，每一次调用都要能判断「这次调成功了没有」
• 评测：标出来的风险点，是真风险还是误报？这里通常需要一个带标注的测试集
• 反馈优化：如果发现「保密条款」这一类老是误报，那就回去改提示词、改规则库，或者干脆把这类条款排除在自动审查外

面试话术示范

「系统我会拆成五层：任务规划、决策路由、工具执行、评测、反馈优化。

但我想重点讲中间两层，因为规划层初期可以用固定模板顶一阵，优化层初期可以靠人工看日志——只有决策和执行这两层，是真的会动到线上数据的，出问题就是事故。

决策层我关心的是……执行层我关心的是每次工具调用能不能拿到明确的成功/失败信号，拿不到的话整个链路就是黑盒。」

三、主动说上线风险

注意三个方面：权限边界、结果校验、人工接管。

面试官问「上线会有什么风险」和你自己讲「这套东西上线前我会先划三条线」，在对方心里是两个完全不同的印象。前者是被考出来的，后者是自带的。

三条线分别在防什么：

权限边界——防它做了不该做的事。 Agent 能读什么、能写什么、能不能直接对外发消息、能不能动钱。默认应该是只读，写权限一个一个开。

结果校验——防它做错了没人知道。 输出在到达用户之前，有没有一道检查？是规则校验、是另一个模型交叉验证、还是抽样人工复核？

人工接管——防它卡住了没人管。 什么条件下必须转人工？转过去之后，人能不能看到它之前做了什么？

【假设场景】一个退款 Agent 的三条线怎么划

假设你要做一个自动处理退款申请的 Agent。

权限边界：它可以查订单、查物流、查退款政策（只读）；它可以生成退款建议；但发起退款这个动作它不能直接做——小额（比如 50 元以下）走自动执行，超过阈值必须人确认。钱的事，权限一定要卡死。

结果校验：它给出的每一个退款结论，都要能追溯到具体是哪条政策的第几款。给不出依据的结论，一律不放行。

人工接管：三种情况强制转人工——用户连续两轮表达不满、金额超过阈值、Agent 自己判断置信度低。转过去的时候，把它已经查到的信息和推理过程一起带给客服，而不是让人从零开始。

面试话术示范

「在讲怎么做之前，我想先说上线前我会划的三条线，因为这三条决定了这个 Agent 敢不敢上。

第一是权限边界，默认只读，写权限一个一个开，涉及钱和对外沟通的一律要人确认。第二是结果校验，每个结论要能追溯到依据，给不出依据的不放行。第三是人工接管，我会定义清楚什么条件必须转人工，以及转过去的时候要带什么上下文过去——接不住的兜底等于没有兜底。」

四、上线之后拿什么看

四个指标：任务完成率、工具调用成功率、人工接管率、失败 trace；四个优化对象：context、prompt、工具、流程。

这一段是四段里最容易被跳过的，但也是最能区分「做过」和「只想过」的。

四个指标各自在回答什么问题：

前三个是体温计，第四个是听诊器。 前三个告诉你「病了」，只有 trace 告诉你「病在哪」。

四个优化对象对应四类病因：

• 完成率低但工具调用都成功 → 大概率是 context 没给够
• 同一类任务反复走错方向 → 改 prompt
• 工具调用成功率低 → 改工具（描述、参数、或者干脆换一个）
• 接管率集中在某个环节 → 改流程，把那个环节拆开或前置

【假设场景】上线第一周，四个指标怎么看

假设你的客服 Agent 上线了，第一周数据是：任务完成率 62%，工具调用成功率 91%，人工接管率 35%。

先别急着改提示词。

工具调用 91% 说明执行层基本是通的，问题不在那儿。接管率 35% 和完成率 62% 大致对得上——也就是说，它不是「做错了」，而是「做不了就转人工了」，这其实是个健康的表现，说明兜底在工作。

接下来要看的是 trace：这 35% 集中在哪一类问题上？ 如果集中在「用户描述不清」，那是 context 或追问策略的问题；如果集中在「查到了信息但不知道下一步」，那是决策层的问题。

面试的时候能把这个推理链讲出来，比背出四个指标的名字有用得多。

面试话术示范

「上线不是结束。我会看四个数：任务完成率、工具调用成功率、人工接管率，以及失败 trace。

前三个是体温计，告诉我有没有问题；trace 是听诊器，告诉我问题在哪。

比如完成率低但工具调用成功率很高，那大概率不是执行层的问题，是 context 没给够；如果接管率集中在某一个环节，那说明流程本身要拆。优化的对象无非四个：context、prompt、工具、流程——但先得知道该动哪一个。」

五、最后成本问题，这笔账算不算得过来

前面四段都在回答「怎么做」。但有一个问题：这东西值不值得做。

要算的是三笔账：

第一笔：单次调用成本。 Agent 和普通功能最大的不同是，一个任务不是调一次模型，是调很多次。 规划一次、决策路由每一步一次、工具返回后再判断一次——一个中等复杂度的任务，六到十次调用很正常。所以成本不能按「一次问答」估。

第二笔：兜底的人力成本。 接管率 35%，意味着有 35% 的量最后还是人在做。这部分人力不能算作省下来了。 上一段讲接管率时，它是个质量指标；到这一段，它直接变成成本指标——这是四个指标里唯一一个横跨质量和成本的。

第三笔：建设和维护成本，摊到单量上。 这笔最容易被漏，也最能决定成败。前两笔是变动成本，这笔是固定成本——大部分 Agent 项目算不过来账，不是因为前两笔贵，而是因为单量摊不平第三笔。

【假设场景】同一个 Agent，一个场景该做，一个不该

假设你要做一个客服 Agent，人工处理一单的成本是 3 元。

• Agent 单次任务的调用成本：0.6 元
• 接管率：35%，转过去的单子还要再花 3 元人力
• 每单变动成本 = 0.6 + 0.35 × 3 = 1.65 元
• 每单节省 = 3 − 1.65 = 1.35 元

看起来省了 45%，不错。但还有第三笔：假设建设加首年维护投入 30 万。要靠每单 1.35 元摊平，需要 约 22 万单。于是同一套东西，在两个场景里结论完全相反：

面试话术示范

「最后我想补一笔账，因为这决定了这个 Agent 该不该做。

我会算三项：单次调用的 token 成本、兜底的人力成本（接管率 × 人工单价），还有建设和维护成本摊到单量上。前两项是变动成本，第三项是固定成本——大多数 Agent 项目算不过来账，不是因为前两项贵，而是因为单量摊不平第三项。

所以我评估的时候会先问单量。同样一套东西，月均两万单可能一年内回本，月均三千单就不该做——那时候固定 workflow 或者维持人工，反而是对的选择。」

为什么这一段最难被问倒： 前四段证明你会设计，这一段证明你知道什么时候不该设计。它和第一段是一对——第一段判断技术上配不配，这一段判断经济上划不划算，两个否定合起来才是完整的判断力。

六、把五段串起来：一份可背的答题卡

这五句开场白是这道题真正的答案。 内容可以现场组织，但顺序不能乱——顺序本身就是在证明你的判断力。

而这五段其实是一条线：配不配做 → 怎么做 → 敢不敢上 → 上了怎么看 → 值不值得做。 一头一尾都是「该不该」，中间三段才是「怎么样」。