Agent面试详解（下）：评测、安全与落地判断
《Agent面试详解》系列：上篇：运行时与上下文 · 中篇：记忆、工具与并发 · 下篇：评测、安全与落地
上篇解决运行时和上下文，中篇解决记忆、工具与并发。系统现在能够持续执行、恢复和控制副作用，但还缺少判断“做得对不对”的能力。
Agent 的困难恰恰在这里：同一个任务可以走出不同轨迹，最终答案看起来正确，过程中却可能越权、浪费预算或依赖错误证据。下篇从 Trace 和测试开始，最后回到安全、产品方向和一道完整系统设计题。
没有 Trace，就调不好 Agent
普通服务的一次请求通常很短，Agent run 却可能跨越几十个模型轮次、工具调用、重试和人工审批。只记录最终答案，几乎无法定位问题。
每次 run 至少应该记录：
- 模型、版本、推理档位。
- Prompt、Tool Schema 和策略版本。
- 每一次状态迁移。
- 工具参数、结果摘要和原始结果引用。
- Token、延迟、缓存命中和费用。
- 错误分类、重试原因和退避时间。
- 人工审批的请求、参数和决定。
- 最终完成证据。
Trace、log 和 audit 不是同一个东西。Log 服务于排障，Trace 还原执行轨迹，Audit 证明谁在什么权限下改变了什么。审计记录不能被 Agent 自己修改。
一条可用的 trace 还要能串起模型调用、工具调用和业务状态。只有时间戳而没有 run_id、step_id、tool_call_id 与状态版本，日志再多也只是分散的碎片。
Agent 应该怎么测试
Agent 的灵活性越强，单次输出越不稳定，越不能只靠几个 happy path。测试需要从确定性最强的底层向完整任务逐层扩展。
第一层：工具单测
验证 schema、权限、超时、错误分类、幂等和副作用。这里尽量不调用真实模型。
工具单测要覆盖“业务拒绝”和“技术失败”的区别。退款条件不满足是不可重试的业务结果，网络超时才可能进入退避重试。错误分类错了，Agent 就会在确定失败上浪费轮次。
第二层：状态机测试
固定模型响应，验证允许和禁止的状态迁移：
RUNNING → WAITING_APPROVAL → RUNNING → COMPLETED
RUNNING → RETRY_WAIT → RUNNING
RUNNING → CANCELED
COMPLETED ↛ RUNNING这层不关心模型有多聪明，只检查 Harness 会不会让一个已取消的 run 继续执行，或让一个未经审批的步骤越过安全门。
第三层：轨迹评测
检查 Agent 是否选择正确工具，是否绕路，是否重复调用，是否在证据不足时提前结束。Anthropic 的 Agent eval 实践强调，多轮评测需要同时观察完整 transcript、工具行为、环境变化和最终结果。Demystifying Evals for AI Agents
轨迹不必和黄金路径逐步相同。更合理的评分方式是定义不可违反的约束、必须获得的证据和允许的工具集合，再对步数、成本和无效调用做软评分。
第四层：端到端沙箱
在隔离环境执行真实任务，例如修复一个带失败测试的小仓库。评分器既检查最终测试，也检查是否越权、是否修改无关文件、是否超过预算。
至少应该监控这些指标：
| 指标 | 意义 |
|---|---|
| 任务成功率 | 最终是否完成 |
| 多次运行一致性 | 同一任务重复执行是否稳定 |
| 无效工具调用率 | Harness 和 Tool Schema 是否清楚 |
| 人工接管率 | 自主能力与风险边界 |
| P95 延迟 | 尾部体验与资源阻塞 |
| 单次成功任务成本 | 比单次模型价格更接近业务价值 |
| 危险操作拦截率 | Guardrail 是否真的工作 |
一次生产失败不应只修当前数据。应把输入、初始环境、关键轨迹和预期行为固化为 regression case，让同类错误以后自动暴露。
安全边界必须在模型之外
Prompt 里的“请勿执行危险命令”不是安全边界。网页、邮件、文档和工具结果都可能带入 Prompt Injection，模型也可能在复杂任务中忘记早期约束。
可靠的控制应放在模型无法绕过的位置：
- Tool Gateway 按租户和 scope 做最小权限检查。
- Shell、浏览器和代码运行在隔离沙箱。
- Secret 只在执行层注入，不进入模型上下文。
- 文件路径、网络域名和 SQL 操作受策略限制。
- 支付、删除、群发等操作必须人工审批。
- 审批页展示具体参数、影响对象和可回滚性。
- 审批后参数变化，原审批立即失效。
- 所有动作可以中止、回放和追责。
OpenAI 的 Agent 实践指南也把 Guardrail、认证授权、严格访问控制和人工接管看成组合防线，而不是单一分类器。A Practical Guide to Building AI Agents
人工审批也不是一个简单的“同意”按钮。审批对象应绑定工具版本、完整参数、资源范围和过期时间；任何参数变化都要重新审批。否则模型先申请一个低风险动作，再在执行前换掉关键参数，审批就只剩形式。
Agent 是热点，还是长期趋势
Agent 这个名字会经历泡沫和洗牌，但“模型调用工具、操作软件、维护任务状态”不会消失。它正在成为一种新的软件交互方式。
未来一到三年的瓶颈，需要按场景判断：
| 场景 | 主要瓶颈 |
|---|---|
| 开放式长期任务 | 模型规划、事实一致性和错误累积 |
| 窄领域工作流 | 系统集成、数据质量和流程改造 |
| 企业高风险操作 | 权限、安全、审计和责任边界 |
| 大规模运行 | 成本、延迟、队列和可观测性 |
| 个性化助手 | 长期记忆、隐私和跨应用授权 |
所以答案不是“模型”或者“工程”二选一：模型决定能力上限，Harness 决定能力能否稳定复现，数据和工具决定 Agent 能否接触真实业务，组织流程决定它能不能创造价值。
行业预测也同时表现出乐观和淘汰。Gartner 预计到 2028 年，33% 的企业软件会包含 Agentic AI；同时预测超过 40% 的 Agent 项目会在 2027 年底前因成本、价值不清或风险控制不足而取消。这更像长期趋势中的集中出清，而不是简单的短期热点。Gartner
ToB 还是 ToC，谁先跑通
需要把用户规模和商业闭环分开。
ToC 产品上线快、反馈直接，编程、搜索、写作等场景容易传播；但付费、留存、跨应用权限和差异化都不容易。通用个人助手偶尔做对一件惊艳的事，不等于用户会把长期权限交给它。
ToB 进入慢，需要过安全、采购、合规和旧系统集成；一旦进入具体流程，价值却更容易量化。例如平均处理时长下降多少、人工复核量减少多少、故障恢复快了多少。
我的判断是：
- ToC 更容易先形成使用规模。
- 窄场景 ToB 更容易先形成稳定收入和可度量 ROI。
- 编程 Agent、专业研究和创作者工具属于 Prosumer 市场，可能最早同时获得使用量和付费。
哪些 Agent 值得做
不要按热度选方向，可以先问五个问题：
- 任务是否高频？
- 数据是否能稳定获得？
- 工具是否有可靠 API？
- 结果是否可以自动或人工验证？
- 失败是否可回滚、可拦截？
这五个问题可以形成一个简单筛选器：高频决定使用机会，数据和工具决定能否执行，验证决定能否迭代，回滚决定可以放出多大自主权。任何一项长期为零，都不适合直接做全自动 Agent。
目前更容易跑通
- 编程、代码 review 和软件维护。
- IT 运维、告警分析和故障诊断。
- 安全事件调查与处置建议。
- 数据分析、研究和报告生成。
- 客服辅助、工单分类和处理建议。
- 企业知识与跨系统流程。
- 财务对账、票据和报表初处理。
- 合同、合规和招聘的第一轮审阅。
这些场景往往有明确输入、稳定工具和可检查输出，适合“Agent 执行，人做关键确认”。
需要谨慎
- 全自动交易和高风险金融决策。
- 医疗诊断与处方。
- 法律最终意见。
- 无人监督的支付、退款和合同签署。
- 直接控制物理设备的开放式 Agent。
不是不能做，而是应该先从建议、草稿、模拟和审批开始。自主程度不是产品宣传中的数字，而是由可验证性和失败代价共同决定的。
最后留一道系统设计题
把三篇文章压缩成一道综合设计题：
设计一个支持多租户、可以连续执行 100 步的企业 Agent。它能够调用内部和外部工具，支持短期与长期记忆，多 Worker 部署，进程崩溃后恢复；上下文不能无限增长；工具调用不能重复产生副作用；危险操作必须人工审批；所有动作可以审计和评测。
一个合格的回答，至少要交付：
- 总体架构和模块边界。
- 同步与异步通信方式。
- Run、step、checkpoint 和 lease 数据模型。
- Token 预算与窗口压缩策略。
- 记忆写入、合并、检索和遗忘机制。
- 乐观锁、租约、分区队列和工具幂等。
- Tool Gateway、沙箱和 Secret 边界。
- Trace、回放、评测和回归数据集。
- 人工审批与高风险操作策略。
面试时不要从框架名开始答。先画模块和信任边界，再描述一次 run 的正常路径、失败路径和恢复路径；接着说明状态如何并发更新、工具如何幂等、上下文如何压缩，最后补评测和安全。这个顺序更容易让讨论落在系统设计上，而不是陷入某个 SDK 的细节。
如果回答只剩 ReAct、向量数据库和某个框架名，说明还停在 Demo 层。如果能够解释事务为什么要短、Worker 为什么用租约、一次性副作用怎样幂等、上下文如何留出输出预算、长期记忆如何遗忘，才真正进入了 Agent 工程。
模型还会继续变强，框架也会不断更换。系统设计、并发控制、权限、可观测性和验证这些基本功不会过时。Agent 岗位真正新增的知识，是如何把这些传统工程能力围绕一个不完全确定的模型重新组织起来。
回到系列：上篇：运行时与上下文 · 中篇：记忆、工具与并发
《Agent面试详解》系列：上篇：运行时与上下文 · 中篇：记忆、工具与并发 · 下篇：评测、安全与落地
微信公众号
欢迎关注「字与码」
如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。
X / Twitter
关注 @ax2_zicode
更即时的技术观察、新文章提醒和一些短想法会发在 X 上。