自动化工程师口述：什么最先出问题

专家圆桌文章通常读起来像算命：含糊、安全，而且到周二就没用了。所以我绕过了 LinkedIn 上的思想领袖，采访了五位真正以 AI 自动化为生的人——两位 n8n 架构师、一家 200 人 SaaS 公司的运维负责人、一位 ML 工程师，以及一位专门收拾别人烂摊子的咨询顾问。

以下是他们对 B2B 自动化下一步发展的真实看法。没有关于"Agent 元年"的预测，只有他们正在实际应对的问题。

1. 瓶颈从模型转向了管道

我采访的每一位工程师都用不同的措辞说了同一件事：模型不再是难点。

GPT-4 级别的推理能力已经足够应对 90% 的业务任务。出问题的都是围绕它的一切——重试、幂等性、状态，以及如何知道一个工作流已经悄无声息地失败了。

"我现在可能只有 10% 的时间花在 prompt 上，另外 90% 的时间都在确保同一个 webhook 触发两次不会生成两张发票。"——n8n 架构师，金融科技

实践要点：把你的自动化系统当作分布式系统来对待，而不是聊天机器人。这意味着幂等性密钥要无处不在。

// Guard against duplicate webhook processing
async function handleInvoiceWebhook(event) {
  const key = `invoice:${event.id}`;
  const alreadyProcessed = await redis.set(key, '1', {
    NX: true,       // only set if not exists
    EX: 86400,      // expire after 24h
  });

  if (!alreadyProcessed) {
    console.log(`Skipping duplicate: ${event.id}`);
    return { status: 'duplicate' };
  }

  return await createInvoice(event.payload);
}

2. 单体 Agent 已过时；小型确定性链才是趋势

那位专门修复故障部署的咨询顾问直言不讳：他在生产环境中看到的大多数"自主 Agent"项目都是过度工程化、监控不足的。

为什么大 Agent 在生产环境会失败

给一个 Agent 一个 12 步的任务并开放工具访问，你会得到非确定性、token 成本飙升，以及像考古学一样的调试过程。当第 8 步失败时，祝你好运能重建原因。

能够可靠交付的团队做法恰恰相反。他们把工作拆分成小型、确定性的步骤，只在真正需要判断的地方才使用 LLM——分类、提取、起草。

# Prefer narrow, testable steps over one mega-agent
def route_support_ticket(ticket: dict) -> str:
    category = classify(ticket["body"])        # LLM: one job
    if category == "billing":
        return assign_to("finance", ticket)     # deterministic
    if category == "bug" and is_urgent(ticket): # rules, not LLM
        return escalate(ticket)
    return draft_reply(ticket)                   # LLM: one job

每次 LLM 调用只做一件你可以用固定示例集进行单元测试的事。这就是 demo 和系统的区别。

3. "人工介入"成为功能而非备用方案

五人中有两位预测：未来两年最成功的 B2B 工具不会是最高自主性的，而是最可审查的。

运维负责人不信任一个能向 4000 名客户发邮件的黑箱。他们需要一个队列，让人类审批边缘情况，系统处理无聊的 95%。ML 工程师称之为"置信度门控的自主性"。

模式：对每个 AI 决策打分，高于阈值自动执行，其余路由给人处理。

result = agent.decide(task)

if result.confidence >= 0.9:
    execute(result.action)
elif result.confidence >= 0.6:
    queue_for_review(result)   # human approves in seconds
else:
    escalate_to_human(task)    # AI stays out of it

这一个设计选择，才是让非技术利益相关者真正批准自动化的关键。

4. 供应商锁定是下一个大遗憾

那位 SaaS 运维负责人发出了最尖锐的警告：团队正在因为上手体验流畅，就把整个业务接入到一个专有平台中。

然后定价变了。或者模型被弃用了。或者供应商被收购了。

她现在的规则：把业务逻辑保持在你自己控制的代码或开源工具中，把模型提供商当作一个接口背后可替换的依赖。

# Abstract the provider so swapping is a config change
class LLMClient:
    def __init__(self, provider):
        self.provider = provider

    def complete(self, prompt):
        return self.provider.generate(prompt)

# Switching from OpenAI to Anthropic to a local model
# shouldn't touch a single line of business logic.

5. 护城河是数据管道，不是 prompt

每个人都能访问同样的模型。他们无法复制的是你干净的、结构化的、有权限管理的公司数据，这些数据在喂给模型。

工程师们一致认为：2025 年竞争优势转移到谁拥有最好的检索层——准确的、新鲜的、在正确范围内针对正确用户的。Prompt 工程是标配。数据工程才是差异化所在。

如果你在构建系统，这意味着什么

剥去炒作，共识出人意料地无聊：

为失败而设计。幂等性、重试和可观测性优先。

组合小型确定性步骤。只在需要判断的地方使用 LLM。

按置信度门控自主性。让人类处理边缘情况。

抽象化你的模型提供商。假设你会切换。

投资你的数据层。那才是真正的护城河。

在 AI 自动化上取得成果的团队，不是最花哨的 Agent 的追逐者。他们把它当作软件来对待——可测试、可监控、在所有正确的地方足够无聊。

这就是五位每天都在交付的人实际看到的未来。不是替代团队的 Agent，而是足够可靠的管道，让团队不再需要守在旁边盯着。

原文发表于 getmichaelai.com