来源

• 原始链接：https://www.youtube.com/watch?v=aHhB3sjGjkI
• 来源类型：视频逐字稿
• 来源标题：Agent 构建 Agent

Agent 构建 Agent 高亮

文本来源是 AI Engineer 频道视频《Agent 构建 Agent》的中文可读转写稿。下面按汉松兴趣画像优先保留机制解释、反常识判断和可复用 workflow，而不是做普通摘要。

一、评估、反馈与故障闭环

背景

这组高亮抓住《Agent 构建 Agent》里最值得保留的反馈闭环：Agent 系统的可靠性主要来自可观测、可复现、可评分的外部结构，而不是一次性把 prompt 写得更漂亮。

另一个选项是领域专家对 trace 进行标注——如果没有真实用户的反馈，我可以请领域专家查看 trace，投入时间，像用户一样给我们反馈。第三步是收集所有带反馈的 trace，并以 JSON 或你使用的任何格式下载到本地。

也就是说，他们可以在我们使用的平台上查看 trace，查看输入、输出，查看所有被调用的工具，查看 agent 的行为，然后通过反馈来标注 trace，告诉我们 agent 的表现如何，以及它应该如何表现。

所以我们要确保了解正在发生的事情，这样编程 agent 一旦发现任何 bug 或问题，就能修复它。

兴趣匹配度很高。它对应汉松持续关注的 Agent 工程化主线：把非确定性系统放进可反馈、可回归、可复盘的闭环里，真正的壁垒在 harness、eval、trace 和人类分诊。

二、上下文、记忆与检索边界

背景

这里讨论的是 Agent 能否拿到正确材料的问题。对汉松有价值的点在于，它把上下文从背景信息变成系统的运行材料：可索引、可缓存、可审计，也可被重新组织。

现在，我们今天要解决的第二类问题不是 eval 数据，而是在实时数据上的差表现。所谓实时数据，是指我们从真实用户、beta 测试者、领域专家——也就是所有正在积极测试和使用系统并给我们反馈的人——那里收集的数据。

核心思路是：我们需要一种方式来确保 agent 正常工作，这就是我们构建黄金数据集的原因。你可以把黄金数据集理解为一套测试用例，只不过是在非确定性场景下的测试用例。

这是因为有些问题足够简单，比如加法、乘法，LLM 的训练数据里就有这些知识，不需要访问任何外部上下文或特定工具就能回答。所以 18% 的问题可以靠 LLM 的权重来回答，其余的不行。

兴趣匹配度很高。这是上下文工程的核心问题：不是给模型更多字，而是让模型在正确边界内获得正确材料，并让材料本身可维护、可验证、可复用。

三、工具、系统与工程约束

背景

这组摘录偏工程实现。它关心的不是模型能力的抽象上限，而是工具、接口、基础设施和生产约束如何决定 Agent 最终能不能稳定工作。

但今天我们会看到如何至少部分地解决这些问题，方法是借助 agent 以及我们在项目中逐步形成的可复用流程。先做一个非常简短的概念回顾：我们可以说，一个 AI agent 基本上就是一个 LLM——它是 agent 的”大脑”。

这是一个现在正在生产环境中运行的真实 agent，而且这个系统找到了越来越多的改进方法。

因为我们从一个没有任何工具的 agent 开始，系统改进它相对容易。但我们也在一个已经经过人工优化的生产 agent 上，将某些 eval 提升了 10%。

兴趣匹配度高。这里能迁移到实际团队建设：工具选择、数据流、权限、成本、延迟和部署形态，往往比单点模型参数更能决定系统上限。

四、人类判断、组织与协作方式

背景

这部分把人放回系统设计里。Agent 越强，越需要人类承担领域判断、目标选择、风险边界和协作组织，而不是把全部责任交给模型。

比如，修改黄金数据集或评分器来让 eval 通过，这不是个好主意，所以我们要明确告诉 AI agent 不要这样做。作为人类，我们可以稍微引导编程 agent，让它去优化目标 agent。

然后，要么我们用 agent 来修复——给 agent 所有上下文、失败模式、trace，让 agent 去修复；要么我们丢弃它——因为有时失败聚类可能是误报，或者是预期行为，或者用户给了我们目前对我们没有实际价值的反馈。所以这里需要一些人类判断。

我们说：“好，基于这 10 条 trace，我们注意到 agent 在这个特定情况下表现不佳，原因是 X。“我们与领域专家一起验证这一切。

兴趣匹配度高。它符合汉松的人机共生框架：AI 承担生成和探索，人类承担判断、责任、品味和组织设计，把人的稀缺性放在更高杠杆的位置。

五、Prompt、规格与行为设计

背景

这里的重点是行为设计。Prompt 不是一句魔法咒语，而是一套分层约束、规格、角色、语气和上下文组合出来的系统界面。

因为 system prompt 包含了所有指令，以及我们对 agent 应有行为和不应有行为的全部定义。在很多情况下，大量优化工作就是调整 system prompt，让 agent 拥有在我们领域内工作所需的全部信息。

一旦我们有了所有聚类，我们还会做一些根因分析——因为我们的编程 agent 可以访问 AI agent 的实际代码，所以它可以做根因分析，尝试理解发生了什么，特别是因为它还能访问每条 trace 的详细信息，可以深入 trace，理解 agent 为什么那样回答，追溯到根本原因。然后它会提出可能的改进方案。

这里我用的是 Mastra，这是一个非常简单的 agent，我把它叫做”mad agent”，但实际上黄金数据集里有多种类型的问题。假设这就是我们最简单的 agent——它只有几条指令，有一个模型，如你所见，还没有任何工具。

兴趣匹配度很高。它把 prompt 从技巧提升为系统设计问题，适合沉淀到汉松的 AI 协作和 agent workflow 方法论里。

整体判断

这篇内容最值得保留的是它把《Agent 构建 Agent》从一次视频分享转成了可迁移的系统判断。核心素材集中在评估、反馈与故障闭环、上下文、记忆与检索边界、工具、系统与工程约束。对汉松后续写作和团队实践来说，它可以作为 AI Agent 工程化素材库的一块：不是追逐单个工具功能，而是持续追问系统如何获得上下文、如何被评估、如何进入生产闭环，以及人类判断应该放在哪些关键节点。