工程团队用AI Agent的实战教训：30分钟/天提效背后

我部署的第一个 Agent Workflow 优雅地优化错了目标。它提示词工整，关闭工单飞快，燃图看起来漂亮——但产出的工作只是技术意义上完成了，实际上错过了客户真正需要的东西，因为"工单已关闭"是它唯一的信号。这次失败教会了我关于 Agent Workflow 的东西，比任何成功的案例都多。

你读到的关于工程团队使用 AI Agent 的文章，大多出自卖平台的人之手。它们描述的是架构图，不是周二实际发生的事。我把 Claude Code agents、MCP 服务器和浏览器自动化放进了一个跨国 iOS 团队的真实 code review 和测试循环中，以我自己的测量口径，在没有降低评审质量的前提下，每个工程师每天节省了约 30 分钟。下面说说是什么真正推动了这个数字，又是什么在悄悄浪费我们的时间。

误区：把输出自动化而不是判断自动化

诱人的说辞是：Agent 写代码，工程师少写。这一环效果最差，也最不重要。

LLM 给你的是互联网的平均水平。在 Swift 这里，训练数据比 JavaScript 或 Python 少，平均水平更差。所以一个被放任自由生成的 Agent 会产出看起来合理的代码，而高级工程师还得逐行阅读才能信任——这并不比手写快多少。时间不是省在让 Agent 构建上，而是省在让它做人类做得慢且厌倦的机械验证上。

每一次 PR review 实际上堆叠着两份工作。机械验证：能不能构建、边界情况是否处理了、有没有人忘了本地化字符串、命名是否与模块一致。以及判断：这个抽象是否正确、它是否符合代码的演进方向、六个月后会不会反咬我们一口。人类做第一份工作很慢，做第二份不可替代。传统的 review 模式迫使高级工程师两份都做，结果机械部分挤占了判断部分，直到评审者走马观花、打下 LGTM，架构漂移就在一次又一次被略过的 PR 中悄然累积。

Agent 的职责是第一个栈，绝不是第二个。

每个 PR 的第一轮评审者。Agent 在任何人看代码之前就先在 diff 上展开，每个维度各一个：正确性与边界情况、与周围模式的一致性、测试是否覆盖了行为变更而非仅仅镜像实现、以及移动端专项检查如硬编码字符串和触控目标是否小于 44pt。每条发现都必须引用文件、行号和具体的失败场景。没有失败场景的发现直接丢弃。正是这一条规则区分了有用输出和"建议提升可读性"式的噪音。我在另一篇关于 review 工作流的文章里详细写了评审的具体机制；重点是：可测量的 30 分钟是从这里来的，不是从代码生成来的。

指标在部署之前就决定了。我犯过的最大流程错误：Agent 已经在运行了才去设定记录指标，所以最初那段时间我是在凭感觉调优。在 Agent 接触工作流之前，先决定你要优化什么。对我们来说，是评审周期时间——在对评审质量负责的前提下——而不是生成的代码行数，不是关闭的工单数。Agent 精确地优化你交给它的那个代理变量，所以这个代理变量必须是真正的目标。

人类对每个架构决策负责。模块边界、离线优先、何时打破 MVVM、何时不重写。一旦人做出了决策，Agent 执行起来更快。它不会做决策。在一个 Williams-Sonoma 的构建中，我搭建了一个模块化的 SwiftUI 代码库，供两个购物 App 共用；那个决策以及背后的品味，我不会交给任何模型。Agent 只是在下面规模化地布线。

没用的是什么，如果重来我会怎么做

票速度 Agent 是这个通病的典型案例：一个只有提示词而没有编码意图的 Agent，会优化最接近的可测量代理变量，然后信心满满地交付错误的东西。解决方案不是更好的模型，而是把评审品味和产品意图编码进工作流本身——用高级评审者会用的同样标准——让 Agent 指向真正的目标，而不是在好日子里才与目标相关的数字。

我会改变的第二件事是信任校准。早些时候我让 Agent 一次触碰太多东西，然后把省下的时间花在重新评审它们的输出上，这完全本末倒置了。要明确地画一条线：Agent 被信任独立做什么、它为什么人类审批而起草什么、它绝对不碰什么。这条线就是全部的设计。往信任方向画错了，你会继承债务；往谨慎方向画错了，你建了一个昂贵的 linter。同样的边界问题贯穿我整个 Claude Code iOS 工作流：搭建只用一下午，决定 Agent 在哪里可以做决策才是长达数月的部分。

一个你可以真正落地的框架

如果你带团队，想让 Agent 进入工作流而不是做表面文章，按顺序问自己四个问题：

什么事情慢是因为它机械，而不是因为它难？ 这是你的第一候选。Review 分流、测试脚手架、变更日志和发布说明、标记缺失的本地化。不是架构，不是产品决策。

记录指标是什么，现在就决定？ 在任何东西跑起来之前写下来。如果你说不出来，你就还没准备好拿 Agent 去对抗它。

人在循环中明确放在哪里？ 说清楚 Agent 独立做什么、为什么审批而起草什么、绝对不碰什么。这是一个设计决策，不是默认。

你标准化了什么、放任了什么？ 标准化那几件会复合的事——评审门槛和完成定义——其余交给团队。当我在多个欧盟站点跑mentorship和评审标准时，全部标准化会杀死本地ownership；什么都不标准化意味着质量会漂移。Agent 让这件事更加锐利，因为不管你标准化了什么，Agent 都会执着且字面地执行它。

所有这些都不需要 swarm 架构或控制平面。它只需要拿走一个你已经用手信任的模式，决定你要测量什么，然后用明确的信任边界把它搬到一个触发器上。从你最确定的那件最小的机械任务开始。用你先写下来的数字测量它。只在测量证明了它的地方扩展。

从 Agent 获得价值的团队不是 Agent 最多的团队，而是把判断保留给人类、诚实地面对他们实际在自动化两份评审工作中的哪一份的团队。

如果你正在思考 Agent 在你团队工作流中的位置，想要一个真实产品上测量过的第二意见，这就是我在策略咨询里做的事。

你团队里哪一件机械任务是所有人讨厌、做起来没人会想念的？那几乎总是一个好起点。

Originally published at veheria.tech/blog/ai-agents-engineering-team-workflow.