执行日志的结构长什么样？关键步骤一次讲清

大模型智能体跑完一次任务，成也好败也好，最可靠的物证只有执行日志：哪一步、进了什么、出了什么、耗了多久，全在里面。这篇教你按字段读记录、按时间线还原现场，把日志的结构一次讲清。

一条记录里藏着的字段

一条完整的日志记录通常包含：步骤序号与名称、动作类型、输入摘要、输出摘要、起止时间、耗时、状态与错误码。字段看着朴素，组合起来就是任务的透视片。可带走的判断：判断一次执行健壮与否，先看错误码的分布，再看耗时的长尾——少数步骤占掉大半时间，优化就从那里下手，比凭感觉乱调有效得多。

七类字段按用途归成四组，读日志时对号入座：

步骤、输入与输出怎么对应

多步任务里，上一步的输出常常是下一步的输入，日志用任务标识把相关记录串成链。沿着这条链，你能看到数据如何一步步变形：原始材料被读入、被整理、被加工、最终成形，哪一环开始跑偏一对照便知。并行执行的分支会有各自的子链，靠同一父标识归拢而不会乱，对应机制见多个工具是怎么并行调用的。无论是秘塔AI搜索的检索任务，还是扣子里编排的多步流程，记录结构都大同小异。

从日志还原一次完整执行

排查顺序建议自上而下：先看最终状态，确定成败与原因大类；再定位第一个异常步骤，前后各看三五条；然后核对输入是否符合预期——多数问题出在输入与设想的偏差上，而非执行本身。比如工具返回的内容异常庞大，后续步骤全被拖垮，这就要回到工具返回的内容太大是怎么办的里的加工方案上找原因。

日志不是越长越好

记录过细会拖慢执行、放大存储成本，过粗又找不到关键现场。合理的做法是分层：常规步骤记摘要，异常步骤记全量，敏感信息一律脱敏后才入档。日志的查阅范围也该有边界——能排错的人看全量，其他人只看摘要，这层把关与权限校验在哪一步的思路一致。留存期同样要有规矩，过期归档而并非无限堆积；人工等待审批的阶段，其进出记录也要入档，见人工审批是怎么暂停流程的。

日志速查表：最终状态定成败大类；首个异常步骤定问题位置；输入偏差定责任边界；耗时分布定优化方向。四步看完，八成问题有了眉目。

把「不是任务不行，而是输入变了」这句话记下来：日志读懂了，你会发现多数失败都有迹可循，剩下的是环境突变，比如页面改版导致定位失效，那又是网页改版了 Agent 怎么办里的专门话题。

跨任务的记录怎么对齐比较

单任务的日志看现场，多任务的日志看规律。把几十次同类任务的日志按步骤对齐，能看出稳定的耗时分布与集中的失败点位：某步骤十次里错三次，就值得单独治理；某环节耗时波动特别大，多半受了外部依赖的影响，重点盯它的上游。对齐的前提是步骤命名规范——同一步骤在不同任务里叫同一个名字，聚合才有意义，命名规则要在一开始就定下来。比较时还要剔除任务本身的差异：输入大小不同，耗时没有可比性，按输入规模归一化后再比才公平。这套横向比较做熟了，日志就从排错工具升级成持续优化的仪表盘。刚开始做横向对齐不必贪多，先挑失败率最高的一类任务，比出结论就落到下一次改进里，循环几轮就能看到明显变化。

关于执行日志再多问三句

• 日志能删吗？：能归档别删除，排错和历史对比都靠它，删除等于销毁物证。
• 记录失败会拖垮任务吗？：写日志本身失败不应影响主流程，成熟的实现会把日志写入做成旁路。
• 多任务并发时记录会混吗？：不会，每条记录都带任务标识与步骤序号，按标识分组就能各自还原。