从 Demo 到生产：AI Agent 工程真正难在哪里

今天参加了一位同事的转正答辩。

答辩里介绍了不少 AI 与数据可视化结合的实践。有些能力已经能够稳定生成内容，也开始进入实际使用阶段。

一开始我以为后面的讨论会围绕项目成果、完成情况和下一阶段计划展开。后来话题逐渐从具体项目转向了几个更大的问题：AI 能力怎样从 Demo 进入生产环境，Agent 的稳定性应该由谁保证，大量生成候选方案以后怎么判断结果好不好。讨论还延伸到了个人成长：经常使用 AI 是否代表能力真的提高了，以及 AI 可以承担越来越多工作以后，个人还需不需要专业主线。

这些已经不只是对某个项目的评价了。它们都在追问同一件事：当 AI 已经能够完成任务后，工程师下一步还要补什么？

这里记录一下我的理解。

能够生成结果，只是第一步

目前很多 AI 项目先解决的是“能不能做出来”。

输入一段内容，模型完成理解和规划，再调用多个工具生成最终结果。如果效果不错，这套流程很容易让人兴奋，因为过去需要人工完成的工作，现在似乎可以自动执行了。

但答辩中的一个反馈让我印象很深：

Demo 能跑，与生产系统可以交付，中间还有很长一段距离。

模型具备完成任务的能力，不代表系统具备稳定完成任务的能力。

进入生产环境后，需要继续回答这些问题：

必须执行的检查会不会偶尔被跳过？
生成失败后应该修改参数，还是完全重新生成？
连续失败时，系统什么时候停止？
中途发生异常，任务能不能恢复？
出现一个低概率错误，能不能还原当时的执行过程？
更换模型后，原来的流程是否仍然可靠？

继续优化 Prompt，解决不了上面所有问题。

以前做传统系统时，我们很自然地会考虑异常处理、日志、监控和状态恢复。到了 AI Agent 里，因为模型“多数时候都能正确处理”，反而容易降低这方面的要求。这一点需要特别警惕。

必须执行的规则，不能只写在 Prompt 里

答辩里讨论了一个很具体的架构问题：哪些约束应该写进 Prompt，哪些必须由程序强制执行。

例如：

每次生成后必须进行质量检查；
检查未通过时禁止输出；
重试次数不能超过上限；
关键操作必须经过权限验证；
输出必须满足规定的数据结构。

这些规则如果只写在 Prompt 中，执行权仍然在模型手里。

模型可能连续很多次都正确执行，让开发者误以为流程已经稳定。但 Prompt 驱动的行为依然存在概率。模型能力变化、上下文变长或者输入出现特殊情况，都可能导致某个步骤被跳过。

顺着这个问题，我现在会把规则分成两类。

允许模型判断的部分，可以放在 Prompt 和 Agent Planning 中。例如分析失败原因、选择修改策略、比较不同候选方案。

必须执行的部分，则应该放进 Hook、状态机或确定性代码中。无论模型是否记得，系统都会强制执行。

以后设计 Agent，只要需求里出现“必须”“每次”“绝不能跳过”，我觉得就应该先问一句：

这条规则为什么还在 Prompt 里？

Prompt 可以引导模型怎么做，但每次都必须执行的检查，还是要由程序控制。这个边界没有划清楚，后面大概率会走弯路。

Agent Loop 需要完整的工程结构

讨论中还有一个问题：怎样让模型在失败后自动修正。

常见做法是先让模型生成结果，再执行质量检查。如果检查失败，就把原因返回给模型，让模型修改参数或重新生成。

看起来只是一个简单循环，真正做起来还要补上不少工程约束。

首先，失败原因需要结构化。

只告诉模型“结果不合格”，模型只能重新猜测。更有用的信息应该包括错误类型、错误位置、预期结果和实际结果。这样模型才能判断是局部修改，还是重新执行整个任务。

其次，需要设置退出条件。

模型不能无限尝试。每个任务都应该有重试次数、执行时间和资源消耗限制。达到上限后，系统需要保留现场并返回明确的失败状态。

然后还要考虑重复执行是否安全。如果一个工具调用会写文件、创建数据或请求外部服务，直接重试可能产生重复结果。工具最好具备幂等能力，或者可以检测当前步骤是否已经完成。

把这些问题放在一起，一个准备进入生产环境的 Agent Loop 至少需要：

结构化的失败原因；
明确的重试上限；
可恢复的任务状态；
幂等或可检测的工具调用；
完整的执行 Trace；
必要时由人接管的入口。

缺少这些约束，所谓 Agent Loop 就只是让模型多试几次，还不能算稳定的工程能力。

没有 Trace，Agent 很难调试

答辩中还提到了 AI 系统的可观测性问题。

传统程序出现故障，可以查看日志、调用栈和监控数据。Agent 系统中还包含模型推理、工具选择和多轮重试，如果只保存最终结果，很多问题几乎无法还原。

一条完整 Trace 至少应该记录：

每轮模型收到的上下文；
模型输出的结构化结果；
模型选择了什么工具；
工具返回了什么；
哪一道 Gate 没有通过；
系统为什么发起重试；
重试时修改了哪些参数；
最终结果来自哪一次尝试；
整个任务消耗了多少资源。

这些记录不只是为了线上排查。

当 Trace 积累到一定数量后，还可以反过来分析系统：哪些失败反复出现，哪些检查应该改成确定性程序，哪些 Prompt 已经过于复杂，哪些任务需要重新拆分。

如果 Agent 总是在同一个地方失败，继续要求模型“再试一次”没有太大意义。需要修改的是系统。

让 AI 大量探索之前，先定义 Eval

答辩中的另一个方向，是让 AI 从辅助执行者进一步变成方案探索者。

过去受时间限制，一个人可能只能设计几个方案。现在可以让 AI 快速生成更多候选结果，再从中筛选。

但这条路有一个前提：必须先知道如何评价结果。

如果没有 Eval，大规模生成只会产生更多需要人工检查的内容。人的工作从亲自制作，变成逐个挑选，工作量不一定会减少。

Eval 可以分成几层：

用程序检查格式、结构、尺寸和完整性；
用量化指标判断结果是否达到最低要求；
用模型辅助评价难以程序化判断的质量；
对少量最终候选结果进行人工判断。

这也提醒了我：AI 越擅长生成，越需要人提前说清楚什么样的结果才算好。

只有自己真正理解什么是好结果，才能把判断写成规则、案例和 Eval。否则模型生成得再多，也只能凭感觉选择。

使用 AI 的次数不等于 AI 能力

转正答辩通常需要评价一个人的成长。过去容易参考完成了多少项目、写了多少代码。现在加入 AI 后，又出现了 Session 数量、Token 消耗、工具调用次数等指标。

但答辩中也提到，这些只能证明一个人在频繁使用 AI，不能证明他的能力已经提高。

这和用代码行数评价工程师差不多。

相比使用量，我觉得下面这些变化更值得观察：

是否开始主动怀疑和验证模型输出；
是否知道哪些工作不能完全交给模型；
是否会把关键规则改成 Hard Gate；
是否能够设计失败重试和恢复流程；
是否会用 Eval 判断修改有没有效果；
是否能通过 Trace 定位概率问题；
是否可以把反复出现的经验写成测试、规则或 Skill；
AI 生成代码的返工次数是否减少；
是否能够对最终结果负责。

所以个人的 AI 学习记录，也不应该只统计“这个月用了多少”。

更有意义的问题是：

这个月解决了哪一种以前解决不了的问题？
在什么地方相信了模型的错误结果？
哪些人工纠正可以改成自动检查？
哪些错误已经重复出现？
新增了哪些可以复用的规则、Eval 或工具？
下一阶段应该刻意训练什么能力？

这种复盘更麻烦，不过它记录的确实是能力变化，不只是使用量变化。

AI 时代仍然需要专业主线

答辩最后还讨论了个人发展问题。

AI 可以帮助一个人处理更多环节。工程师可以参与需求分析、设计、开发、测试和内容生产，过去清晰的角色边界正在变淡。

但这并不意味着专业主线不再重要。

以数据可视化为例，模型可以辅助生成代码、分析数据和探索设计方案。但如果自己缺少对视觉表达、交互、数据和用户理解过程的长期积累，就很难判断模型给出的方案是否合理。

AI 让工程师能够参与更多环节，但判断模型给出的结果是否合理，仍然依赖长期积累的专业能力。

个人后续的发展，可以围绕自己的主线向外扩展：

向下补软件工程、测试、可观测性和系统设计；
向上理解用户问题以及结果为什么有用；
学习 Agent、Harness、Gate 和 Eval；
把个人经验整理成规则、案例和 Skill；
逐渐从完成任务，走向定义问题和验收结果。

如果主线不清楚，很容易变成什么都能借助 AI 做一点，但没有哪一类问题能够真正判断和负责。

以后再看 AI 项目，我会直接检查这些问题

这次答辩让我记下了下面这份清单。以后再看一个 AI 项目，我不应该只看它生成了多少结果，还会继续检查：

哪些步骤由确定性程序保证？
哪些判断交给了模型？
失败原因是否结构化？
重试有没有明确上限？
重复执行是否安全？
能否还原完整执行过程？
任务中断后能否恢复？
Eval 是否真的对应结果质量？
项目经验有没有变成可复用的工程资产？

对个人也是一样。

会使用模型已经不再稀缺。下一阶段需要继续积累的，是识别模型的不可靠性、建立工程边界，并且对最终结果负责。能不能做到这些，可能就是 AI 工程师从“会用工具”走向“能够交付”的分界线。