来源
- 原始链接：https://www.youtube.com/watch?v=pSto5YaNGUo
- 来源类型：视频逐字稿
- 来源标题：Agentic AI 工程师
Agentic AI 工程师高亮
文本来源是 AI Engineer 频道视频《Agentic AI 工程师》的中文可读转写稿。下面按汉松兴趣画像优先保留机制解释、反常识判断和可复用 workflow，而不是做普通摘要。
一、评估、反馈与故障闭环
背景
这组高亮抓住《Agentic AI 工程师》里最值得保留的反馈闭环：Agent 系统的可靠性主要来自可观测、可复现、可评分的外部结构，而不是一次性把 prompt 写得更漂亮。
第二个是 diagnostics agent，帮你诊断生产中已有的 trace，因为我们从用户那里了解到，阅读这些 trace 花了他们大量时间，能从 coding 环境直接启动分析 trace 的工具对他们很有帮助。
构建 eval 套件有两种方式：一是指标和评估标准（eval），二是数据集本身（包含你需要满足的测试用例）。一开始，你可以与领域专家坐下来，尝试写出覆盖该功能或 agent 的 eval 指标和标准，但大多数团队都知道这有点难——你无法从一开始就预判完整的 eval 套件。
但本质上，完整的 eval 套件是一个发现的产物：随着时间推移，从用户反馈和生产故障中，你会收集到指标、标准，以及额外的数据集用例——这些通常代表 agent 需要处理的边界情况或难点。
兴趣匹配度很高。它对应汉松持续关注的 Agent 工程化主线：把非确定性系统放进可反馈、可回归、可复盘的闭环里，真正的壁垒在 harness、eval、trace 和人类分诊。
二、上下文、记忆与检索边界
背景
这里讨论的是 Agent 能否拿到正确材料的问题。对汉松有价值的点在于，它把上下文从背景信息变成系统的运行材料：可索引、可缓存、可审计，也可被重新组织。
你收集的用例越多，看到的生产数据越多，你的 agent 就越好，评分也越高。所有这些合在一起，构成了一个端到端的可以 Agentic 运行的循环。
在进行 agent 评估时，总体来说我们会检查：上下文是否完整？即 agent 是否拥有完成任务所需的所有上下文？
你进入离线循环：一旦构建好你的评估系统，就评估、优化、测试、在测试数据集上提升准确率。
兴趣匹配度很高。这是上下文工程的核心问题：不是给模型更多字，而是让模型在正确边界内获得正确材料，并让材料本身可维护、可验证、可复用。
三、工具、系统与工程约束
背景
这组摘录偏工程实现。它关心的不是模型能力的抽象上限，而是工具、接口、基础设施和生产约束如何决定 Agent 最终能不能稳定工作。
评估通过之后，你通常就到了发布（ship）阶段：把 agent 部署到生产。这可以是一次代码更新，也可以是对某个 agent 平台的直接更新，或者你本地 harness 中的 agent 更新。
大家也都清楚，这里有两个概念：一是离线循环（offline loop），在你构建的过程中，对 agent 进行迭代、测试、评估、改进，如此往复；另一个是我们所说的在线循环（online loop），即 agent 部署到生产后，你监控它的 trace，诊断问题，然后将结果反馈到优化循环中，持续迭代，维护多个版本的 agent。
原因在于：与 coding agent 不同，其他领域的 agent 处理特定的流程，而这些流程因公司而异，因此对 agent 所在的环境来说是高度专属的。
兴趣匹配度高。这里能迁移到实际团队建设：工具选择、数据流、权限、成本、延迟和部署形态，往往比单点模型参数更能决定系统上限。
四、人类判断、组织与协作方式
背景
这部分把人放回系统设计里。Agent 越强，越需要人类承担领域判断、目标选择、风险边界和协作组织，而不是把全部责任交给模型。
希望我们展示了一些关于如何用 Agentic AI 工程师构建 agent 未来的真实洞见。停止调试，让 agent 做那些繁琐的工作，有问题欢迎联系我们。
你基本上需要的是连接到各种数据源的 connector：你的所有 trace 存放在哪里，你从哪里获取 incident 信息，这也可以是你的 ticketing 系统，或者 Slack 上用户反馈 agent 故障的地方。连接好之后，自然也有不同的目标平台。
好，所以我们让一个 agent 来做筛查 trace 的工作。>> 是的，正如当前时代所说：你为你的 agent 设计 loop，让它们能在后台自主处理这些事情。
兴趣匹配度高。它符合汉松的人机共生框架：AI 承担生成和探索，人类承担判断、责任、品味和组织设计，把人的稀缺性放在更高杠杆的位置。
五、Prompt、规格与行为设计
背景
这里的重点是行为设计。Prompt 不是一句魔法咒语，而是一套分层约束、规格、角色、语气和上下文组合出来的系统界面。
基本上 spec 告诉你的 coding agent 要构建什么，目标平台完全由你选择。
所以首先是识别 agent 遇到了什么故障模式，然后将这些故障模式按根因和来源进行分组——这可能是 agent prompt 的某个部分。
但归根结底，评估 agent 时你希望评估所有这些方面，而不仅仅是某个孤立的维度。
兴趣匹配度很高。它把 prompt 从技巧提升为系统设计问题，适合沉淀到汉松的 AI 协作和 agent workflow 方法论里。
整体判断
这篇内容最值得保留的是它把《Agentic AI 工程师》从一次视频分享转成了可迁移的系统判断。核心素材集中在评估、反馈与故障闭环、上下文、记忆与检索边界、工具、系统与工程约束。对汉松后续写作和团队实践来说，它可以作为 AI Agent 工程化素材库的一块：不是追逐单个工具功能，而是持续追问系统如何获得上下文、如何被评估、如何进入生产闭环，以及人类判断应该放在哪些关键节点。