小米面试官：“聊聊Agent Harness可观测性”，我：“这是生产级 AI 项目必须补上的一课”，面试官震惊：“这还用你说，我让你聊细节！”

一、为什么 Agent 能跑起来了生产里还是不稳面试官可能会这么问“现在模型能力、工具调用、MCP 都成熟了为什么 Agent 真正上生产还是容易翻车”这个问题很关键。很多录友会说“因为模型还会幻觉。”对但不够。Agent 生产不稳不只是模型本身的问题而是长链路执行系统的问题。普通聊天机器人答错一句话最多是回答质量差。但 Agent 不一样它会规划任务、调用工具、读写状态、修改文件、发起请求、触发工作流。它的每一步输出都会变成下一步输入。这就带来一个很大的差异Agent 的错误会沿着执行链路传播。第一步目标理解偏了后面计划全偏。第二步工具选错了后面拿到的证据就是错的。第三步参数传错了工具返回异常Agent 可能又基于异常结果继续推理。跑到最后结果看起来还挺像那么回事但中间过程已经乱了。这也是为什么 Demo 阶段和生产阶段的关注点完全不同。Demo 阶段大家看的是“它能不能跑通一次”生产阶段大家看的是能不能稳定跑很多次能不能在异常情况下恢复能不能控制成本能不能解释过程能不能复盘失败能不能在版本迭代后不退化如果没有可观测性这些问题全都只能靠猜。Agent长链路执行中小偏差被逐步放大的过程所以面试时可以这样回答Agent 生产不稳的根因不是某一个 Prompt 没写好而是长链路执行过程不可见。生产级 Agent 必须把计划、上下文、工具调用、状态变化、成本和评估结果全部纳入观测否则出了错无法定位也无法持续改进。这句话比单纯说模型会幻觉要高级得多。因为你已经从模型视角切到了系统工程视角。二、Agent Harness 可观测性到底是什么面试官可能会这么问“你怎么理解 Agent Harness 可观测性它到底要观测什么”先给一个定义Agent Harness 可观测性是对 Agent 执行过程中的目标、计划、上下文、工具调用、状态变化、成本、风险和结果质量进行全链路记录、度量、回放和评估的能力。注意不是只记录输入输出。Agent 真正麻烦的地方不在输入和输出而在中间过程。一次复杂任务里Agent 可能经历这些步骤用户给出目标。Agent 先拆计划。然后检索资料。再调用工具。再根据工具返回结果更新状态。再重新规划。再生成结果。最后还要自检或交给 Evaluator 评估。这里面任何一步都可能出问题。所以 Agent 可观测性至少要覆盖七类对象目标原始任务是什么过程中有没有被改写。计划Agent 是怎么拆任务的每一步是否服务原始目标。上下文哪些信息被塞进模型来源是什么是否过期或污染。工具调了什么工具参数是什么返回了什么耗时多久。状态任务状态、记忆、文件、数据库记录发生了什么变化。成本每一步消耗多少 Token、时间、工具资源。评估最终结果是否正确中间轨迹是否合理。Agent Harness可观测性沿执行链路采集目标计划上下文工具和结果这里有一个非常重要的判断可观测性不是为了事后甩锅而是为了让 Agent 的每一次执行都能变成可分析、可复现、可改进的工程数据。一个生产级 Agent 系统不能只问结果对不对。还要问过程合理吗证据充分吗工具调用必要吗有没有越权动作有没有重复步骤有没有成本异常有没有潜在漂移这些问题回答清楚了Agent 才算从会干活走向可治理。面试里可以这么说Agent Harness 可观测性本质上是在 Harness 里给 Agent 装眼睛。它不只看最终答案而是把一次任务拆成目标、计划、上下文、工具、状态、成本、评估这些可观察对象让系统能定位错误、复盘过程、控制成本并把失败样本沉淀成后续改进。三、Agent 可观测性和普通日志有什么区别面试官可能会这么问“你们不是已经有日志、监控、链路追踪了吗为什么 Agent 还要单独做可观测性”这个问题很容易答错。很多人会说“我们把 Agent 输入输出打到日志里。”这不够。普通日志主要记录的是接口什么时候被调用请求参数是什么返回状态码是什么服务耗时多少有没有异常堆栈这些对传统后端系统很有用。但 Agent 的问题往往不是接口 500。Agent 最常见的问题是它为什么选择这个工具它为什么忽略了某段关键上下文它为什么跑到另一个子任务去了它为什么把工具返回结果理解错了它为什么重复规划了 5 次这些问题普通日志回答不了。因为普通日志记录的是发生了什么。而 Agent 可观测性还要解释它为什么这么做。普通日志和Agent Trace在定位任务偏差上的区别举个例子。用户让 Agent“分析最近 7 天订单异常原因。”普通日志可能只看到POST /agent/run 200call search_orders successcall query_refund_rate successLLM response success看起来都成功。但最终结论错了。为什么错普通日志看不出来。Agent Trace 应该能看到原始目标是订单异常原因Agent 第一步把目标改写成了退款率异常检索时只查了退款数据没查支付失败数据工具返回里有支付通道超时但模型没有纳入结论最终回答只归因到退款策略这样你才能定位问题不是工具失败而是目标改写偏了 证据选择偏了。这就是 Agent 可观测性和普通日志的差异。普通日志适合看系统有没有挂。Agent Trace 适合看任务有没有做对。面试里可以这么答传统日志关注服务状态Agent 可观测性关注执行意图和决策过程。Agent 出问题时HTTP 状态码可能全是 200但任务已经偏了。所以生产级 Agent 需要结构化 Trace把 Plan、Action、Observation、State Diff、Context Source 和 Eval Result 串起来而不是只打输入输出日志。四、一个 Agent Trace 里到底要记录什么面试官可能会这么问“如果让你设计 Agent Trace你会记录哪些字段”这个问题很实战。不要只说记录输入输出。一个真正可用的 Agent Trace至少要分两层任务级 Trace和步骤级 Step。任务级 Trace 记录这次任务的全局信息trace_id一次任务的唯一 IDuser_goal用户原始目标normalized_goal系统改写后的目标agent_versionAgent 版本model_version模型版本policy_version工具权限、成本预算、审批策略版本start_time/end_time任务开始结束时间final_status成功、失败、降级、人工接管total_tokens/total_cost总消耗final_eval最终评估结果步骤级 Step 记录每一步发生了什么step_id第几步step_type规划、工具调用、观察、总结、评估current_goal当前步骤服务哪个子目标context_refs本步使用了哪些上下文来源model_input_summary输入摘要model_output_summary输出摘要tool_name调用了哪个工具tool_args工具参数tool_result_summary工具返回摘要state_before/state_after状态变化latency_ms耗时tokensToken 消耗risk_level风险等级eval_result本步是否合理Agent Trace Schema如何支持失败任务回放和评测这里面有几个字段特别重要。第一个是context_refs。因为很多 Agent 错误不是模型突然变差而是上下文给错了、给多了、给旧了。你必须知道本步推理到底用了哪些文档、哪些历史消息、哪些记忆。第二个是state_before和state_after。Agent 是会改变环境的。它可能写文件、改数据库、创建工单、发邮件。如果没有状态差异记录出事后你不知道它到底动了什么。第三个是eval_result。不要等最终答案出来才评估。长链路任务里中间步骤就要评估。因为越早发现偏差修复成本越低。面试时可以这么说我会把 Agent Trace 设计成任务级和步骤级两层。任务级记录原始目标、版本、状态、总成本和最终评估步骤级记录每一步的计划、上下文来源、模型输出、工具调用、状态差异、成本和局部评估。这样失败后既能看全局链路也能定位到具体哪一步开始出问题。五、长链路任务里怎么发现 Agent 已经跑偏了面试官可能会这么问“Agent 跑一个长任务执行了二三十步你怎么判断它没有偏离原始目标”这个问题和之前聊过的 Agent上下文漂移 强相关。长链路任务里Agent 跑偏不是突然发生的。它通常是慢慢偏的。一开始只是处理一个小问题。后来这个小问题变成子任务。再后来子任务抢走主线。最后 Agent 忘了最初要干什么。所以漂移检测不能只看最终答案要看执行过程里的信号。常见信号有五个第一当前动作和原始目标相关度下降。比如原始目标是分析订单异常Agent 连续几步都在优化报表格式这就危险了。第二子任务耗时超过预算。支线任务可以做但不能无限做。一个格式修复占掉整个任务 70% 的步骤就说明主线被挤压了。第三重复步骤增多。反复查询同一个接口反复重写同一个计划反复调用同一个工具都说明 Agent 可能卡住了。第四目标表述发生变化。最初是分析订单异常原因中间变成分析退款率再变成输出退款建议这就是目标漂移。第五关键证据没有被使用。工具返回里有重要异常信号但 Agent 后续步骤完全没引用说明注意力可能被别的信息带偏了。长链路Agent任务中根据轨迹与目标主线距离检测漂移工程上怎么做可以加三类机制。目标锚点每隔 N 步把原始目标、当前计划、最近动作放在一起让系统判断是否还在朝目标推进。检查点评估每完成一个子任务就评估它对原始目标的贡献而不是只看它有没有完成。漂移告警当相关度低、重复率高、子任务超预算时触发重新规划、人工确认或任务终止。注意这里不是让模型每一步都自我反省。那样成本会爆。更合理的是在关键节点做轻量检测。比如每 3 到 5 步做一次或者在工具失败、重复调用、预算超限时触发。面试里可以这么答我不会只看最终结果判断 Agent 是否跑偏而会在 Trace 里持续记录当前动作和原始目标的关系、子任务进度、重复步骤、目标改写和关键证据使用情况。工程上可以设置目标锚点和检查点评估一旦出现连续低相关动作、重复工具调用或子任务超预算就触发 Re-Planning、降级或人工确认。六、工具调用出问题怎么定位是模型错、参数错还是工具错面试官可能会这么问“Agent 调工具失败了你怎么判断问题出在模型、参数、权限还是工具本身”Agent 工具调用的问题不能笼统归因成模型不稳定。生产里要分清楚故障类型。否则你根本不知道该修 Prompt、修 Schema、修权限还是修工具服务。常见工具调用故障可以分成五类。第一类工具选择错误。用户问订单数据Agent 却调用了知识库搜索。这是模型在工具选择上出了问题通常要优化工具描述、路由策略或工具候选集。第二类参数生成错误。工具选对了但参数错了。比如日期格式不对、字段名不存在、必填参数缺失。这类问题要靠 JSON Schema、参数校验、错误反馈和少量示例修。第三类权限边界错误。Agent 调用了不该调用的写操作。比如用户只是询问退款规则Agent 却尝试执行退款。这类问题不能靠 Prompt 兜要靠 Tool Registry、权限策略和高风险动作审批。第四类工具服务异常。工具本身超时、接口 500、依赖服务挂了。这不是模型问题要走重试、熔断、降级和告警。第五类结果理解错误。工具返回是对的但 Agent 看错了。比如接口返回支付失败率升高Agent 却归因成退款率升高。这类问题要记录工具返回摘要、证据引用、输出校验和评估结果。Agent工具调用故障从工具选择到结果理解的逐段归因路径所以工具调用可观测性要记录完整链路工具调用前记录为什么选这个工具。工具调用中记录工具名、参数、权限、耗时、重试。工具调用后记录返回结果、模型如何解释结果、结果有没有被最终答案引用。这里有一个很实用的排查顺序先看工具是否存在。再看权限是否允许。再看参数是否通过 Schema。再看工具服务是否成功。再看模型是否正确理解返回结果。这个顺序能把大部分问题拆开。面试里可以这么答工具调用失败不能一概说是模型幻觉。我会把链路拆成工具选择、参数生成、权限校验、工具执行、结果理解五段每段都有结构化 Trace。选择错了修工具描述和路由参数错了修 Schema 和校验权限错了加审批边界工具异常走熔断降级结果理解错了做证据引用和输出评估。七、Agent 成本失控应该监控哪些指标面试官可能会这么问“Agent 一跑长任务 Token 就爆你会怎么做成本可观测和控制”这个问题很现实。很多 Agent Demo 看起来很猛一到生产就贵得离谱。原因也很简单Agent 不是一次模型调用。它是多次规划、多次工具调用、多次上下文拼接、多次自检、多次重试。一次用户请求背后可能烧掉几十次 LLM 调用。所以 Agent 成本不能只看总 Token要拆到步骤级。至少要监控七类指标第一总 Token 和单步 Token。总 Token 只能告诉你贵不贵单步 Token 才能告诉你贵在哪一步。第二上下文长度。很多成本不是推理难而是上下文塞太多。尤其是把历史记录、检索文档、工具返回全部原样塞进去成本很快爆。第三工具重试次数。工具失败一次不可怕反复失败才可怕。每次失败都可能触发新的模型分析和重试。第四重复规划次数。Agent 不断 Re-Planning说明它对任务状态不确定或者前面步骤没有推进。第五无效步骤占比。有些步骤执行了但对目标没有贡献。这个指标越高说明 Agent 在空转。第六模型路由成本。是否所有步骤都用了大模型简单分类、格式转换、规则判断能不能用小模型或规则第七端到端延迟。生产系统里时间也是成本。Agent 跑 3 分钟才给结果很多业务场景根本不能接受。Agent成本失控来自循环重试和上下文膨胀的过程成本控制不是简单砍 Token。乱砍 Token可能把质量也砍没了。更合理的做法是做预算分层简单任务给低预算。复杂任务给中预算。高价值任务才允许高预算。超过预算时不是直接失败而是触发策略压缩上下文换小模型减少候选工具停止低价值子任务要求用户补充信息转人工或降级输出面试里可以这么答Agent 成本可观测不能只看总 Token要拆到每个 Step。重点看单步 Token、上下文长度、工具重试、重复规划、无效步骤、模型路由和端到端延迟。控制上要做预算分层超过阈值后触发上下文压缩、小模型路由、停止低价值子任务、降级输出或人工接管而不是简单让 Agent 继续烧。八、线上失败样本怎么沉淀成 Harness 的长期改进面试官可能会这么问“Agent 线上失败一次之后你怎么保证下次不会再犯同样的错”这个问题直接考 Harness 思维。很多团队处理线上失败是这样的出错了。查一下日志。改一下 Prompt。上线。然后祈祷下次别再出事。这不叫工程化。真正的 Harness 改进要把失败样本变成资产。一次线上失败至少要沉淀出四类东西第一失败归因。到底是目标理解错、上下文缺失、工具选择错、参数错、权限错、模型误读还是评估漏掉没有归因就没有改进方向。第二评测样本。把这次失败任务变成固定测试用例。以后 Prompt 改了、模型换了、工具描述改了都要跑一遍。第三Harness 规则。如果是结构性错误就要补到 Harness 里。比如高风险写操作必须审批连续三次工具失败必须停止目标相关度低于阈值必须重新规划。第四监控指标。如果这次失败有早期信号就要把信号变成告警。比如重复调用、成本异常、关键证据未引用、工具返回错误率升高。线上Agent失败样本沉淀为评测规则和监控资产的闭环这就是 Harness Engineering 的核心精神不要只修这一次错误要把错误修进环境里。Agent 犯错不可怕。可怕的是每次犯错都靠人肉记忆下次换个版本又犯。生产级 Agent 的进步不是靠写一个完美 Prompt而是靠持续积累失败样本、评测集、规则、监控和回归流程。面试里可以这么答线上失败后我会先从 Trace 做失败归因把问题定位到目标理解、上下文、工具、权限、状态、成本或评估某一层。然后把失败任务沉淀成评测样本把结构性问题沉淀成 Harness 规则把早期信号沉淀成监控指标。以后每次模型、Prompt、工具或 Harness 改动都用这些样本做回归避免同类错误反复出现。九、如果让你设计一套生产级 Agent 可观测系统你会怎么答面试官可能会这么问“如果让你从 0 设计一套生产级 Agent 可观测系统你会怎么设计”这类问题不要上来就讲技术组件。先讲目标再讲架构。目标很简单让每一次 Agent 执行都可追踪、可解释、可复盘、可评估、可改进。架构可以拆成六层。第一层Trace 采集层。在 Harness 的关键节点打点任务开始、计划生成、上下文组装、工具调用、状态更新、评估、任务结束。这里要注意采集点应该在 Harness 里而不是散落在各个 Agent Prompt 里。否则后面一定乱。第二层事件存储层。把 Agent 运行事件结构化存起来。原始输入输出可以脱敏存储结构化字段用于查询分析。比如 trace_id、step_id、tool_name、tokens、latency、status、risk_level、eval_score。第三层指标计算层。从 Trace 里计算关键指标任务成功率平均步骤数平均 Token工具失败率重试率漂移告警率人工接管率评测通过率第四层可视化与告警层。给研发看 Trace 回放。给业务看任务成功率和成本。给运维看延迟、失败率、异常工具。高风险动作、成本超限、连续失败要触发告警。第五层回放与评测层。线上失败任务可以一键回放。回放时固定输入、上下文、工具返回判断新版本有没有修好旧问题。第六层改进闭环层。把失败归因沉淀到 Prompt、工具描述、权限策略、上下文策略、评测集和 Harness 规则里。生产级Agent可观测系统从Trace采集到Harness改进的架构闭环这个系统不是一天建成的。刚开始可以很轻。先把 Trace 跑通。再补工具调用和成本指标。再做失败样本回放。最后做评测闭环和自动告警。但方向一定要对不要把 Agent 可观测性做成日志大屏要做成 Agent 改进系统。面试里可以这么答我会把生产级 Agent 可观测系统拆成 Trace 采集、事件存储、指标计算、可视化告警、回放评测和改进闭环六层。Harness 在关键节点统一打点记录计划、上下文、工具、状态、成本和评估失败任务进入回放和评测集结构性问题沉淀成规则、权限、预算和上下文策略。最终目标不是多一个监控大屏而是让 Agent 的每次失败都能推动系统变稳。最后说一句。Agent 真正进生产后最怕的不是它犯错。最怕的是它犯错了你不知道它为什么错。没有可观测性Harness 就没有眼睛。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】