Canvas 如何驱动 AI Agent 开发反馈闭环

对于构建 AI agent 的团队来说，反馈闭环应该已经是个熟悉的概念：观察 agent 的行为，找出需要改进的地方，发布改动，衡量结果。理论上，每一轮都建立在前一轮之上，直到这个闭环变成飞轮，agent 每转一圈都更有效。

实际上，我们很多人还处在被动应对的状态。用户报告了异常，成本飙升，或者 eval 分数下降。有人打开日志，靠 grep 加祈祷来还原发生了什么。眼前的问题也许解决了，但下一次排查又从零开始。真正的反馈闭环始于问题，而不只是故障。agent 在任务上表现如何？它在哪些地方吃力？成本和延迟由什么驱动？上一次改动有帮助吗？这些答案应该指导迭代改进：更好的埋点、更精准的 eval 和测试用例、排好优先级的修复，以及证明这些修复有效的证据。麻烦在于，闭环的每个环节往往散落在不同地方。遥测数据在 Honeycomb，源码和部署历史在 GitHub，工作在 Linear 里跟踪，而决策和上下文消失在 Slack 的讨论串里。Honeycomb 的 Canvas 把这些上下文汇聚到同一次调查中：在这里，你和你的个人 Honeycomb agent 一起查看生产数据。它查询你的遥测数据，验证假设，在成千上万次运行中找出模式，把证据和发现整理在一块共享的无限画布上。随着 GitHub、Linear、Slack 等集成不断增多，它能把这些发现与产生它们的代码关联起来，转化为工单或改动建议，再回到数据中衡量改动是否奏效——闭合闭环，而不是只留给你一份诊断和一张待办清单。Canvas 不只是在反馈闭环的某一个阶段帮上忙；它编排整个闭环：埋点、调查、排优先级、改进、验证。我们这么说是因为我们用 Canvas 构建了 Canvas。在开发它的调查 agent 时，我们把 Canvas 指向它自己的遥测数据，找出 agent 表现不佳的地方，按严重程度和出现频率给问题排序，把它们变成 Linear 工单和 prompt 改动，再对比改动前后的结果。最重要的是，它帮我们在用户之前发现了问题。在本文接下来的部分，我们会逐一走过这个闭环的每个阶段，从让其他一切成为可能的遥测数据开始。

关于可用性的说明： Canvas 的连接器（包括 GitHub 和 Linear）目前处于 Beta 阶段，预计 2026 年秋季正式可用。关于这意味着什么，参见beta 计划详情。

阶段 1：为你的 agent 埋点（这样才有东西可看）

要调试，agent 得先留下痕迹。**遥测（Telemetry）**就是这条痕迹：每一次模型调用、工具调用和交接，都附带耗时、token 和错误信息。每一步是一个 span；一次请求产生的 span 组成一个 trace；一次完整 agent 运行产生的 trace 共享同一个 conversation，这样你就能把整个过程当成一个完整的故事来读。没有遥测，就无从排查。这是唯一一个不能跳过的阶段。

共同语言：OpenTelemetry GenAI 约定

工具怎么知道哪些 span 是模型调用、哪些是工具调用？当然是靠命名规范！OpenTelemetry（OTel）是一种厂商中立的遥测上报方式，它的 GenAI 语义约定把 AI 相关的部分（conversation、agent、tool、token、prompt）统一命名在 gen_ai.* 前缀之下。按这套标准埋点，Honeycomb 无需任何自定义胶水代码就能读懂你的数据；日后增加或更换后端，你也不会被绑死。

让 Agent Timeline 生效的三个属性

Honeycomb 的 Agent Timeline 能把一次 agent 对话渲染成一个可读的故事。只要你的 span 上带三个属性，它就能亮起来；完整配置见 Agent Timeline 埋点文档：

• gen_ai.conversation.id: 一个共享 ID，打在同一次运行的所有 span 上。
• gen_ai.agent.name: 这个 span 由哪个 agent 产生。在多 agent 系统中，正是它让时间线为每个 agent 分出独立泳道，而不是糊成一团。给每个 agent 和子 agent 起一个各不相同的名字；没有名字的一律显示为 “Unknown”。
• gen_ai.operation.name: 这一步属于哪一 类：模型调用（chat）、工具执行（execute_tool）、一个 agent 调用另一个 agent（invoke_agent）、检索步骤（retrieval）等等。

把这三样打通，Agent Timeline 就能跑起来。其余的都是锦上添花。

然后，丰富它

这三样能让时间线跑起来，但再加几样会让它有用得多：token 数量（成本和上下文膨胀的信号）、作答的模型名称和版本、结束原因，以及每个工具的名称、参数和结果——很多“模型坏了”的 bug，最后发现其实是“工具返回了垃圾”。记录下真实的提示词和响应，你就能按模型当时看到的样子读一遍对话；由于这些内容可能很大或包含个人数据，你可以选择完整记录、只记元数据，或先在 Collector 里做脱敏。如果你会对输出做质量打分，把评估分数作为 span 事件附加上去，质量就成了可查询、可追踪趋势的东西。完整教程见我们的 Agent Instrumentation Guide，从头到尾讲如何用 OpenTelemetry 给 agent 做埋点。

让 Canvas 帮你找出缺口

Canvas 自带一项技能，会从三个方面主动审计你的 agent 遥测。

1. 评估对 OpenTelemetry GenAI 语义约定的遵循情况，找出缺口或偏差
2. 验证遥测是否满足 Agent Timeline、GenAI 面板、成本核算等 Honeycomb 功能的要求
3. 建立一批常见的运维和业务问题，然后检查你的遥测能否回答它们。

这样设计出来的遥测不仅能用于调试，还能用来分析行为、指导改进、衡量实验、展示业务价值。打开一个 Canvas，用你的 agent 名字调用这项技能即可：

“/agent-instrumentation-audit audit the investigator agent”

要获得最佳效果，请启用 GitHub 集成，这样 Canvas 就能自动为你完成修复。

阶段 2：弄清 agent 做了什么

有了遥测数据，你终于能做到日志从来做不到的事：完整观察一次运行如何一步步展开。大多数排查都从这里开始。打开 Agent Timeline，它像故事一样从上往下读。点进任意一步，GenAI 面板会显示当时发生了什么。这就是模型眼中的对话，问题通常就藏在这里。而且由于这些 AI span 与普通的后端 span 位于同一条 trace 中，时间线会越过模型继续延伸，进入工具在底层发起的数据库查询或 API 调用。你不必手动沿着时间线一步步走。Canvas 自带查询和理解 agent 会话所需的 skill 和工具。把 Canvas 指向这段对话，然后问：

“/conversation-investigation debug checkout agent conversation 7f3abde”

你可以手动调用 skill，也可以用自然语言告诉 Canvas 你想了解某个会话的什么。

“总结 checkout agent 上会话 7f3abde 的成本和延迟，按操作和 subagent 拆分。找出延迟瓶颈以及 token 用量过高的原因。”

Canvas 会深入探查该会话，用遥测数据检验自己的假设，并返回答案以及支撑这些答案的查询链接。它还能把 Agent Timeline 放到画布上，并附带一个深链接，让你随时打开该对话的完整时间线，近距离查看某一步。由于这一切位于画布上而非聊天线程中，每个人和每个 agent 都能在同一个共享工作区里协作。

现在你可以读懂任意一次运行并解释它。但一段奇怪的对话只是个例。接下来，让我们拉远视角：这是偶发事件，还是贯穿数千段对话的某种模式露出的冰山一角？

阶段 3：找出值得修复的问题

拉远视角意味着换一个问题：不再是“这次运行发生了什么？”，而是“我的 agent 这周做的所有事情里，哪些反复出错，其中哪些值得我花时间？”你不可能逐条读完数千段对话，也不该这么做。先开始收集关于对话的信号。有些信号你可能已经在产出：对输出的评估分数、主题/复杂度/意图之类的分类标签，以及点赞/点踩这样的用户反馈。把这些交给 Canvas，它就能在数千次运行中发现模式，而无需任何人逐条阅读。大多数时候，你只需要问：

“总结我们的评估分数，并在低分对话中找出模式。”

“把带有负面反馈的对话拉出来，对主题做聚类。”

“按问题主题和复杂度对失败分组，再按数量排序。”

对于任何在生产环境中的 agent，还有两个问题值得一问：它的成本是多少，又为什么慢？让 Canvas 按 agent 和操作给你的最昂贵对话排序，检查 prompt caching 是否真的划算，或者标记出那些空烧 token 却没有进展的混乱循环；也可以让它聚焦速度：延迟分布、各 agent 的首 token 时间，以及哪些工具调用处在关键路径上。

“把本周最贵的对话按 token 总用量排个序，按 agent 和操作拆开，再告诉我前几个的成本主要花在哪。”

“给我看看各个 agent 首 token 耗时的分布，把最慢的路径标出来。挑一个慢对话拉出 trace，看看时间都花在哪。”

Canvas 自己决定怎么回答：跑查询、抽样代表性运行，或者当某个数值属性是关键线索时用上 BubbleUp。你只管描述要找的模式，不需要知道背后的机制。底层上，它能把一个大问题拆成并行的调查，再权衡、排序最可能的原因。十几个症状往往收敛到两三个根因，而其中一个通常占了大头。这个排序告诉你下一步该修哪里。

你从“我在 debug”变成“我理解我的 agent 的失败分类”。这套分类告诉你接下来该往哪投入。现在该把洞察变成行动了。

阶段 4：把修复发出去

把洞察变成行动，这一步大多数可观测性工具都留给你自己做：它们把问题摆出来，然后把你丢到另一个标签页去写工单、改代码。Canvas 留在流程里，因为它接进了真正动手修的地方。agent 的修复很少是一行代码补丁。更常见的是：一段需要改措辞的 prompt、一个把模型带偏的工具描述、一个拉错上下文的检索步骤、一道缺失的护栏，或者一个本该路由到更强模型或专用工作流上的难题。你刚才排过优先级的那种失败模式，通常就指向其中之一。启用 GitHub 和 Linear 连接器后，Canvas 可以在调查过程中直接动手：

• 开一个 pull request。
• 建一张 Linear 工单，把失败模式连同证据一起记下来。
• 把回归和最近上线的代码改动关联起来。

写操作始终要经过审批。Canvas 先起草改动，把将要发生的事完整展示给你，在你批准之前，不会有任何合并、发布或归档。

“按严重程度和出现频率对已观测到的失败模式排序，在 Checkout Agent 项目里开 Linear 工单。给它们设定优先级，状态标为：To do。”

“针对 honeycomb/checkout 起草一个 PR，改写退货政策提示词，修掉我们刚发现的失败模式，同时开一个 Linear 工单，把最糟糕的五段对话作为证据链接进去。”

工单和 PR 都诞生在调查过程之中，所以它们自带上下文。审查者能看到失败的对话，而你刚发布的改动就成了下一步要验证的对象：它管用吗？这个循环的最后一环，就是证明它管用。

阶段 5：证明它管用

确定性软件里，bug 修好就是修好了，但 agent 不会给你这种了结。同一个改动可能对某类请求有帮助，却伤害另一类；而且每次运行的输出都不一样，“我试了一下感觉好多了”算不上证据。你需要拿同样的信号，在真实流量上做前后对比。这时候，埋点时设置的版本标签就派上用场了。如果你的 span 带有 gen_ai.agent.version（或 service.version），Canvas 就能把旧版本和新版本的失败模式率、eval 得分、成本和延迟一一对齐——或者把一个实验变体和另一个对齐——不用靠部署时间戳去猜。

“对比 investigation agent 在 v2.5 前后的 URL 幻觉失败率和平均准确率得分。这次修复减少了失败，同时没有在其他地方掉质量吗？”

Canvas 把两组数据都取出来，并排画成图，告诉你目标指标有没有动——以及其他指标有没有跟着动。

最危险的改动，是修好了你正盯着的问题，却弄坏了你没在看的地方，所以度量必须能捕捉到那些从不触发告警的缓慢退化。把 eval 得分按时间画成图，当某条线拐弯时，GitHub 连接器让 Canvas 读取那个时间点前后合并的 PR，指出最可能是元凶的那个 diff。无论哪种结果，你都用证据而不是指望，闭合了循环的一圈：修复管用或不管用，你都清楚接下来该继续查什么。而且因为对比、得分和你的笔记都留在 canvas 上，下一个人是从一个更清晰的起点开始，而不是一张白纸。证明一次修复管用是一回事，让它持续管用是另一回事。有两个动作能把这种一次性检查变成持续监控：

• 把对比结果保存为 board。 让 Canvas 把 before/after 视图提升为一个 Honeycomb board，快照就变成了团队持续盯着的实时仪表盘，而不是临时画布上一次性的东西（创建 board 是写操作，所以和 PR 一样要走审批流程）。
• 设置触发器，让它自己去查。 给真正重要的指标挂上触发器，回归一出现你就能立刻收到。开启自动调查，Canvas 会直接打开一个假设、支撑查询，以及对原因的第一版猜测，全都已经摆在 board 上。

为持续运转而设计

Canvas 让整个循环像是一个连贯的动作，每一轮都为下一轮提供输入：你在过程中积累的 skills、boards 和 triggers，会让团队从“有人抱怨了才去调试”转向“运行一个能自我观察的系统，把发现和排好优先级的行动交到你手上”，而且每一轮都更聪明、更快。我们自己的 agent 就是靠这个循环来构建 Canvas 的。打开一个，开始转起来。

充分发挥 Canvas 的作用

几个能让 Canvas 调查效果更好的习惯：

• 在画布上画。 选中图形、在热力图上圈出区域、高亮聚类。这比用文字描述你看到的东西更快也更准确。如果你在某个具体时间窗口看到延迟尖峰，直接选中它，而不是把时间戳打出来。agent 能感知画布内容和你的当前选择。

• 展开工具调用，检查推理过程。 Canvas 会展示它执行的每一次查询和拿到的每一个结果。核对它查的数据集、时间范围和过滤条件对不对。当 agent 得出意料之外的结论时，问题往往就出在这里的错误假设上。

• 中途干预。 你不必等 agent 跑完，也不用先把它停掉再改方向。直接发一条新消息，它立刻调整。如果你发现它在调查进行到第三步时走错了路，直接说就行。

• 把团队的经验写进 Skills。 你的团队知道一些 Canvas 不知道的事：哪些服务最关键、你们的发布节奏是什么样的、你的 agent 应该具备哪些能力、有哪些新功能和项目可能影响 agent 的运作方式、对你们的 agent 来说什么算“正常”。把这些上下文写成 skill。Canvas 会自动引用它们，而且它们会在每一次调查、每一个团队成员之间不断累积。有两个值得尽早建：一个跟踪当前进行中的项目和功能，一个用于发布——把某次变更的 Linear 项目和 GitHub 仓库交给它，问它上线后该盯什么，然后让它在发布前确认回答这些问题所需的埋点已经就位。

• 接入 GitHub、Linear 和其他连接器。 GitHub 把源码和部署历史交给 agent，它就能把回归关联到发布它的那个 PR，对照真实代码审查你的埋点，并提出具体的 diff。Linear 提供项目和 issue 上下文，让它了解你正在做什么，并能直接从一次调查中开出范围清晰的新工单。你接入的每一个数据源都是给 agent 的更多上下文。这个列表还在快速变长，更多集成正在路上。

• 给触发器写清楚的描述。 自动调查触发时，你的触发器描述会成为 Canvas agent 的上下文。不要只写指标名；把调试指令写进去，或者指定 agent 应该调用哪个 skill。“routing agent 错误率 > 5%。先查是否与部署相关，再按类型排查工具故障”比“错误率高”能让 Canvas 更快进入状态。

• 告诉 Canvas 如何组织它的发现。 默认布局已经够用，但你可能想要把执行摘要放在顶部、按特定方式分组，或者换一种视觉重点。直接提要求就行：“把这些重新组织成摘要部分和详情部分”，或者“把成本图表并排放，方便对比”。选中画布上的某个区域，让它重新排列那一块，同样可行。

• 使用 Pages。 Canvas 可以在一次调查中创建多个页面，按受众或关注点来组织内容时很好用。你可以要求在详细调查之外再加一个“Summary and Actionable Takeaways”页面，也可以每个假设一个页面，或者按不同的利益相关方分页。

• 用 Canvas 构建 eval 和数据集。 让 Canvas 起草一个 eval，并拿真实的生产对话做采样验证，看它站不站得住；也可以让它挑出一批对话，做成回归或 eval 数据集。它会把发现的失败案例变成测试用例，防止这些问题再次出现。

• 实时协作。 Canvas 支持多人同时使用。事故期间把画布分享给队友，所有人看到的都是同一份发现，有上下文，实时同步。你也可以把自己的观察和 agent 的发现钉在一起。

• 通过 MCP 在你自己的工作流里使用 Canvas。 你不必待在 Honeycomb UI 里。启用 Honeycomb MCP server 之后，Canvas 的工具会出现在你日常使用的任何地方，你可以在当前标签页里直接发起调查、拉取发现，或者操作 Canvas。

• 使用反馈机制。 当 Canvas 的回答特别好或特别差时，点一下大拇指向上/向下图标，并填写反馈问卷。这些会直接送到我们团队，帮助我们为所有人改进 Canvas。你也可以让 agent 替你把反馈提交给我们。