做 Agent 的团队很容易陷入一个循环：上线后看日志，找几条失败样本，改 prompt，再跑一遍评测。有效，但很费人。模型越能干、Agent 承接的任务越多，人工翻 trace 的速度就越跟不上生产数据。Langfuse 联合创始人 Marc Klingen 在 AI Engineer World’s Fair 2026 的分享里，把问题说得很直接：下一阶段的重点已经不是继续手调 prompt，而是让 AI 接手改进流程里的大部分机械劳动。
这场演讲最有价值的地方，是没有把“自我改进”包装成全自动魔法。Marc 给出的边界很清楚：AI 可以分析 trace、发现错误簇、提出实现修改、维护部分数据集与评测项，再对候选版本做回测；人仍要决定优化方向，并审核会改变评价边界的动作。换句话说，团队要自动化的是爬坡过程，不是把“哪座山值得爬”也交给模型。
从“写 prompt”转向“经营循环”
Marc 用一句来自业界的说法概括变化：“I don’t write prompts, I have loops.” 这句话听起来有些夸张，却准确描述了 Agent 工程的重心迁移。早期模型能力弱，开发者连一次调用能否稳定完成任务都没有把握，工作自然围绕单个 prompt 展开。到了 2025、2026 年，模型已经能处理多文件修改、长链路推理与工具调用，单次执行不再是唯一难点。真正拉开产品质量差距的，是团队能否持续从真实使用中取回信号，并把信号变成下一轮可验证的改动。
Marc 回忆，Langfuse 刚开始做产品时，他们也尝试过“GitHub issue 自动变 PR”一类应用。当时系统只能可靠修改单个 HTML 文件，多文件编辑很快失控。如今编码 Agent 能在仓库里搜索、修改、测试和提交候选方案，过去只能由工程师完成的改进动作，已经有相当一部分适合交给模型。
能力提升并没有消除工程问题，只是把瓶颈向上推了一层。以前团队问“模型能不能完成这个任务”，现在更常问：
- 生产中的失败样本是否被完整记录？
- 数据集是否仍能代表用户的真实请求？
- 评测项能否捕捉最近出现的错误？
- 新版本到底改善了质量，还是只迎合了少数测试样本？
- 用户的修改、拒绝和批准，能否自动进入下一轮分析？
这些问题都指向同一件事：Agent 产品需要一个持续运转的反馈闭环。
在线数据与离线实验必须连在一起
Marc 展示的参考栈有两个部分。在线侧负责 tracing 与 monitoring，记录用户如何调用 Agent、Agent 经过了哪些步骤、工具返回了什么，以及最终结果是否被接受。离线侧负责 dataset、experiment 与 eval，用固定样本比较不同实现，确认候选修改有没有带来稳定收益。
传统软件里，这两套系统经常分开。可观测平台保存生产日志，机器学习平台管理离线实验。对 Agent 来说，分开会制造两个盲区。只做离线评测，数据集很快会和生产中的真实请求脱节；只看在线日志，团队又没法在发布前系统比较新旧版本。Langfuse 的产品逻辑正是把两边接起来，让生产 trace 能沉淀为数据集和评测案例，实验结果也能回到部署与监控环节。
理想闭环大致是：
- Agent 在生产环境执行任务，系统保存完整 trace。
- 用户的编辑、批准、拒绝或显式评分形成反馈信号。
- 分析 Agent 聚类失败案例，找出重复出现的错误模式。
- 系统补充数据集与评测标准，重现这些错误。
- 改进 Agent 提出若干修改，例如更换模型、调整上下文、修改工具或提示词。
- 候选版本在离线数据集上回测，与当前版本比较。
- 人审核方向和风险，决定合并、继续实验或放弃。
- 新版本上线后，再从真实使用中收集下一批信号。
过去，这八步里有一半以上要靠人手。工程师每周抽样 trace，复制失败输入，手写评测规则，再逐项尝试修改。Marc 的判断是，模型已经足以承担其中大量重复劳动，尤其是失败分析、修改建议和批量回测。
“自我改进”有很多层，不是一枚开关
演讲引用了一种分层循环的视角。最底层是模型逐 token 预测；往上是工具调用、任务执行、反思与重试；再往上是修改 Agent 的实现、维护数据集和评测项；最高层则涉及业务目标与价值判断。层级越高，改动影响越大，也越需要人参与。
目前最成熟的用法，是让 AI 在既定边界内提出实现修改。团队已经有生产 trace、数据集和评测标准，Agent 可以围绕明确指标“爬坡”。它可能尝试换模型、重新组织上下文、增加工具调用，或者把最近流行的技术方案拉进实验。只要评价边界不变，这类工作很适合自动化，因为模型能并行检查大量错误案例，也不会因为人工耐心耗尽而停止。
更靠上的自动化正在出现。Marc 观察到，一些团队开始让 AI 维护数据集和 eval。例如客服 Agent 的离线样本原本来自上线前的设想，真实用户却会问出完全不同的问题。分析 Agent 可以从生产 trace 中识别新的请求类型，提出应加入数据集的样本。它还能发现旧评测没有覆盖的错误，比如回答泄露内部术语、语言与用户不一致、篇幅过长，进而建议新的 evaluator。
风险也在这里变大。数据集和评测项定义了系统追求什么。如果生成改动的 Agent 同时随意重写评价标准，它可能把问题改成自己容易通过的样子，最后得到一套分数漂亮、实际更差的系统。Marc 因此反复强调：会改变优化边界的动作，仍应由人审核。
人该留在哪一层
一个完全人工的改进流程，质量可以很高，代价是团队要持续投入时间。一个完全自动的流程几乎不占人力，却可能制造大量 token 消耗和一堆看似合理的改动，最终没人能解释系统为何变成现在这样。
Marc 想要的状态在两者之间：人停留在高层，负责目标、边界和审核；AI 接管低层的搜索与验证。团队不必每天翻几千条 trace，却仍能控制产品往哪里走。
这个分工背后有个很现实的原因：Agent 的目标本身会移动。以客服自动化为例，公司一开始可能只说“缩短等待时间，减少人工回复”。真正上线后，团队才会逐渐发现任务包含退款、账户、技术排障、情绪安抚和合规限制。每遇到一种新错误，产品边界就清楚一点。团队像是在飞行中组装飞机，很难在第一天写出完整规格。
人最该做的，并非逐条修复所有失败，而是判断哪些失败值得解决。生产中总会出现偏门请求，如果为了一个不属于产品职责的案例改变整个 Agent，很可能造成过拟合。工程师需要说清楚：“这是核心能力，应该进入数据集”，或者“这是产品明确不处理的情形，不要为它扭曲系统”。
用户行为比单独打分更有用
闭环能否运转，还取决于信号质量。许多产品只在结果下方放赞和踩，但真实用户很少主动评分。Marc 提醒团队关注隐式反馈：用户是否修改了 Agent 草稿、是否批准建议、是否要求重写、是否直接采用结果、客服人员最终发送了哪个版本。
这些行为天然带着任务语境。内部员工把 Agent 起草的回复改了三处再发出，编辑差异本身就是具体反馈；代码审查者批准 PR，说明结果至少达到了可合并门槛；用户反复纠正同一个术语，则说明系统对业务语言理解有问题。把这些信号和完整 trace 绑定，分析 Agent 才能追溯错误从哪里产生。
这种做法还有一个好处：产品团队不需要额外发起庞大的标注项目。反馈原本就存在于工作流里，只是过去没有被结构化保存。系统可以定期汇总一批高价值信号，每天或每周运行一次分析与实验循环。
Langfuse 的演示：让 changelog writer 修正“内部黑话”
Marc 用 Langfuse 自己的 changelog writer 做了一个具体演示。随着工程团队大量使用 AI，发布频率提高，更新文档、changelog 和社交媒体内容反而成了新瓶颈。过去工程师每月发布一个大功能，花几小时写说明还能接受；现在每周都有很多改动，沟通速度开始限制交付速度。
他们搭了一个写作 Agent：代码合并后，Agent 根据 PR 更新文档与 changelog，再通过 GitHub PR 交给人审核。审核者可以直接批准，也可以提出修改要求。批准和 change request 都会作为反馈写进可观测与评测系统。
随后，一个编码 Agent 读取这些 trace 和反馈，得出几项诊断：changelog 的事实准确性不错，格式也基本合规，但清晰度偏低；人类编辑比例仍然较高；最典型的问题是把内部工程术语直接写给用户。例如代码注释里的 ingestion pipeline、batched eval queue 属于实现细节，客户并不会用这些词理解产品。
Agent 接着完成几步工作：
- 从历史案例中提取“内部术语泄露”的失败样本；
- 修改数据集，使问题可以稳定重现；
- 增加面向用户语言的 evaluator；
- 调整 changelog writer 获得上下文的方式和写作指令；
- 用同一批样本回测 V1 与 V2。
回测结果显示，V2 保持了原有的格式合规与事实准确性，同时在 user-facing language 指标上取得正向变化。因为这个 Agent 不直接发布生产内容，只会向仓库提交 PR，团队容许它自动合并部分改进；如果下一版仍有问题，审核反馈会进入下一轮。
演示的重要之处不在于“AI 会写 changelog”，而在于整个改进链条有可追踪的证据。失败来自真实审核，评测能复现失败，候选修改经过新旧版本对比，最终产物仍受版本控制与审查保护。这里的自我改进是工程流程，不是模型凭感觉重写自己。
自动化边界要看失败半径
Marc 的例子给了一个实用判断标准：Agent 能自动走多远，取决于它犯错后会影响什么。changelog writer 的改进 Agent 只提 PR，不直接发布，失败半径较小，因此可以更“YOLO”一些。涉及付款、权限、医疗建议或面向客户的自动操作时，团队就应提高审核门槛。
可以把权限分成三档：
- 只读分析：读取 trace，聚类问题，生成报告。风险最低，适合先落地。
- 提议改动：修改 prompt、代码、数据集或 evaluator，但只提交候选版本，由人审核。
- 自动部署：回测通过后直接发布。只适合指标可靠、回滚成熟、影响范围可控的场景。
很多团队一上来就追求第三档，反而跳过了最有收益也最容易验证的前两档。让 Agent 每周整理失败簇、生成可复现样本、提出带证据的修复建议，已经能省掉大量人工。等团队确认评测与回滚机制可信，再逐步放权更稳妥。
为什么 trace 数据会变成核心资产
演讲最后转向一个容易被忽略的基础设施问题：当 Agent 开始分析 Agent，系统的读负载会快速增加。传统 LLM 可观测平台偏写入密集，持续接收 trace、评分与事件。自我改进循环则会反复扫描历史数据，聚类错误、生成数据集、执行回测，同一批记录可能被多个分析 Agent 多次读取。
这会改变数据系统的要求。存储必须足够便宜，查询必须能扩展，保留期也要更长。一年前的 trace 过去可能只是审计记录，如今却可能成为新 Agent 理解长期错误模式的重要上下文。如果平台因为成本只保留很短时间，或者大量采样丢弃 trace，团队未来想训练 evaluator、重建数据集时就会发现材料已经不存在。
Marc 因而提出“拥有自己的数据层”。这里不只是开源立场，也是一项工程选择：团队要能长期保存未过度采样的执行数据，能把它导出并交给新的分析工具，不被某个商业平台的留存策略锁死。随着模型读取数据的规模远超人类，这种可访问性会越来越重要。
一套更现实的落地顺序
如果把演讲里的方法压缩成实施路径，我会从可观察、可复现、可审核三个条件开始，而不是直接做“自动优化 Agent”。
第一步，确保每次执行都能还原。至少要记录输入、模型与版本、prompt 或 Agent 配置、工具调用、关键中间结果、最终输出和延迟成本。没有完整 trace，后面的诊断只能猜。
第二步，把工作流里的隐式反馈接进来。审批、编辑差异、重试、撤回、人工接管都比孤立的点赞更具体。信号要和对应 trace 绑定，否则只能看到“不满意”，看不到为何不满意。
第三步，建立一小套可信数据集。数量不用大，但每条都应来自真实任务，覆盖核心能力与已知失败。评测项也不要一口气堆满，先抓住事实正确、格式约束、安全边界和用户语言这类能影响交付的指标。
第四步，让 AI 只做分析与提议。要求它给出失败簇、证据 trace、可复现样本、候选修复和回测结果。人审核后再合并。这个阶段能检验 Agent 是否真的减少劳动，而不是把人工从“改 prompt”变成“审查一堆低质量建议”。
第五步，根据失败半径逐渐放权。可逆、受版本控制、有自动回滚的改动可以先自动化；会直接影响客户或资金的动作继续保留人工门禁。
我的判断：真正的护城河是闭环质量
模型、框架和 prompt 技巧都会快速扩散。团队今天找到的一个提示词技巧，明天可能被更强模型直接抹平。生产反馈如何被保存、筛选、解释和转成实验，却高度依赖产品自己的用户、任务与历史数据，竞争者很难复制。
所以我赞同 Marc 的主线：Agent 工程正在从“把一次调用调好”，转向“把改进循环建好”。但“自我改进”这个词容易让人高估自动化程度。系统不会凭空知道什么是好产品，它只会更高效地追逐团队给出的边界。边界错了，循环转得越快，偏离也越快。
最值得自动化的，是人不擅长长期坚持的工作：阅读海量 trace、整理重复失败、批量提出候选修改、反复回测。最不该外包的，是目标判断、风险取舍和评价标准的最终决定。把这条线画清楚，自我改进才会从演示里的漂亮概念，变成可以在生产环境长期运行的工程系统。
原视频：The Self-Improving OSS Agent Stack — Marc Klingen, Langfuse。演讲者 Marc Klingen，频道 AI Engineer，录制于 AI Engineer World’s Fair 2026。
