Agent 项目越来越常出现在简历里，但面试官对这类项目也越来越敏感。如果候选人只说“我让模型调用工具完成任务”，很容易被认为只是做了一个演示。真正值得讲的，不是模型能不能调函数，而是它调错了怎么办、有没有权限、参数是否合法、失败后系统能不能恢复。
Agent 的核心风险在于：模型输出的是意图和参数，但真实系统执行的是动作。动作一旦涉及订单、账号、文件、消息、外部 API，就不能把决定权完全交给模型。
工具调用前必须有参数校验
模型生成的参数可能缺字段、类型错、范围不合法，也可能把用户自然语言里的模糊表达误解成确定操作。比如用户说“帮我查一下最近的订单”，模型可能不知道“最近”是 7 天还是 30 天；用户说“取消它”，模型需要知道“它”指的是哪个订单。
所以工具层要有结构校验、必填字段检查、枚举值限制和业务规则校验。参数不完整时应该让模型追问用户，而不是猜一个默认值直接执行。
权限是 Agent 的硬边界
Agent 不能因为模型“理解了用户请求”就越过权限。用户能看哪些数据、能执行哪些动作、是否需要二次确认，都应该由业务系统判断。尤其是写操作、删除操作、支付操作、对外发送消息这类动作，最好有确认、审计和回滚设计。
查询类工具：风险是泄露越权数据，更稳处理是按用户身份过滤数据。写入类工具：风险是改错状态，更稳处理是参数校验加二次确认。
- 外部 API：风险是造成真实成本或副作用，更稳处理是限额、重试上限、审计日志。
- 删除/取消类动作：风险是难以恢复，更稳处理是高风险动作人工确认或延迟执行。
失败路径比成功演示更有含金量
Agent 演示通常展示成功路径，但面试更关心失败路径。工具超时怎么办？工具返回部分成功怎么办？模型调用了错误工具怎么办？连续失败会不会无限重试？
成熟系统会记录每次工具调用的工具名、参数、执行结果、耗时、错误码和模型上下文版本。这样坏例复盘时，才能知道问题出在模型理解、参数生成、工具执行还是业务权限。没有这些日志，Agent 出错后很难定位。
一个能打动面试官的表达
可以这样描述 Agent 项目：我把模型当作决策建议层，而不是直接执行层。工具执行前会经过参数校验、权限校验和风险分级；高风险动作需要用户确认；每次调用都有日志，失败后按错误类型决定重试、追问、降级或转人工。这样讲出来，项目就不再像“函数拼接”，而像一个可上线的 AI 后端系统。
如果是多步骤 Agent，还要考虑中间状态。一个任务执行到第三步失败，前两步产生的状态是否需要回滚？是否可以从失败点继续？用户能否看到系统已经做了什么？这些问题决定 Agent 是玩具流程还是可交付系统。面试里主动提中间状态和补偿，通常会比只展示工具列表更有说服力。