Agent as Feature：当 AI 替代后端逻辑会发生什么

一个 webhook 触发了——用户往你的报销应用里传了一张收据。放在 2024 年，这个请求会先打到路由，控制器校验 payload，服务层用正则或者写好的模板去抽字段，最后存库。二十行字段映射，四十行边界处理，再加一百行"万一收据是日文怎么办"。

到了 2026 年，同一个 webhook 直接路由给一个 agent。Agent 看了这张收据，知道这是晚餐费用，把商家、金额、税费、小费全抽出来，做好分类，发现金额超了单餐限额就标记违规，最后写入记录。没有 controller，没有 parser，没有硬编码的字段映射。

Gartner 预测到 2026 年底，最多 40% 的企业应用会内嵌任务专属的 AI agent，而 2025 年这个数字还不到 5%。我觉得这是一个真实的转变，也打算亲自试一试。

这篇文章就是我在想："agent as feature"到底意味着什么，哪些地方会出问题，以及为什么我仍然觉得值得投入。

传统后端就是一棵决策树

你写过的每一个后端功能，结构都差不多：

Request → Router → Controller → Service → Database → Response

一个功能就是一条代码路径，一个边界情况就是一个 if。来了新需求？树上再长一个分支。后端永远只干代码写好的事，不多也不少。

这是它的优势——你能测试、能审计、能精确预判它周六凌晨三点出问题时会怎么表现。但代价是：改行为就得改代码。凡是碰过 2000 行路由函数的人，都知道那是什么体验。

拿客服工单系统来说。光是路由逻辑——优先级判断、部门分配、升级规则、SLA 计算——可能就是几千行业务逻辑，写好几个月才搞定，规则一变就得维护。每次有人说"能不能顺便看看客户是不是企业版，走不同的路由"，树上就多一个分支，而棵树本来就够难读了。

以前只能这样写软件，因为计算机不会推理，只能执行指令。所以我们写了一棵又一棵庞大的决策树，试图把所有可能的决策路径都编码进去。

但如果计算机会推理呢？

如果功能本身就是一个 agent？

不再把请求丢给一个走决策树的 controller，而是路由给一个能理解意图、动态执行的 agent。

把 agent 当后端这个思路来自 Go Wombat。他们的想法是：controller 和 router 被围绕"意图"做推理的 agent 取代。客户端不再为某个具体动作调某个具体 endpoint，而是告诉系统"我想要什么结果"，agent 自己判断怎么做。他们最关键的一个结论是：最难的不是搭 agent，而是划清边界——哪些事该 agent 决定，哪些事该用确定性代码处理。

Dan Shipper 在 Every.to 说过一句话，我一直记着："应用里的每个功能，本质上就是给 agent 的一条 prompt，告诉它要达成什么结果。"你不再写命令式代码，而是写声明式目标。

代码的样子变了：

// 传统写法：从收据里提取报销字段
const vendor = extractField(receipt, 'vendor', vendorPatterns);
const amount = parseAmount(extractField(receipt, 'amount', amountPatterns));
const category = categorize(vendor, amount, merchantDB);
const violations = checkPolicy(amount, category, userTier);
// ... 后面还有一大堆
​
// Agent 驱动：描述目标
const result = await agent.process({
  task: "从这张收据里提取报销信息",
  input: receipt,
  schema: ExpenseSchema,
  tools: [db.write, policy.check, notification.send]
});

这里我做了简化。真实的 agent 驱动功能照样需要护栏、schema 校验、错误处理。但代码确实不一样了——你告诉它你要什么，而不是一步步写清楚怎么做。

这个体会是我在做 OpenClaw 时得到的。一开始我想用代码把 pipeline 卡死，然后在代码里调 AI——等于把 agent 塞进一个僵硬的控制流里。但 LLM 的输出本来就不太适合被僵硬约束。我越约束，越像是在跟工具较劲，而不是用它。后来我想通了：让 agent 来主导。给它目标和工具，让它自己决定路径。给它空间去想清楚。

Webhooks + Agent 模式

那实际用起来是什么样的？模式是这样的：

1. 外部系统通过 webhook 推送事件
2. 事件路由到 agent，而不是 controller 函数
3. Agent 接收 payload，推理接下来该做什么，然后通过定义好的工具去执行

Webhook 事件
    ↓
事件路由
    ↓
Agent（推理意图）
    ├── 工具：写数据库
    ├── 工具：调外部 API
    ├── 工具：发通知
    └── 工具：转人工处理

Agent 自己决定调哪些工具、按什么顺序调。它不是在跑一个预写好的脚本，而是在对当前情况做推理。

如果你做过事件驱动架构，这个结构会很眼熟。区别在消费端。Everworker.ai 说得很直白："系统在事件发生时推送事件，AI Worker 立刻响应。"同样是 push 模式，但另一头不是确定性 handler，而是一个会推理的 agent。

Motia 这个框架把这件事做得更彻底——agent 和 API endpoint 是同一种基本构件。后端里的一个"步骤"到底是函数还是 agent，只是实现细节。

更宏观地看，用 InfoQ 的话说："AI Agent 变成了执行引擎，后端退回到治理层。"MCP（Model Context Protocol）正在让这件事更容易标准化，给 agent 提供了统一的工具和数据访问协议。之前用自定义 API 也能做，但 MCP 之于 agent 与工具的交互，就像 HTTP 之于浏览器和服务器。

LangGraph 处理有状态的 agent 工作流，CrewAI 做多 agent 编排。从我观察到的情况看，它们已经不只是实验品了——有团队开始在上面搭真实系统。

后端变成了治理层

如果 agent 负责推理和执行，后端到底还干什么？

答案是：治理层。认证、限流、审计日志、schema 校验、工具访问控制。后端定义 agent 能做什么——哪些工具、哪些权限范围、哪些 schema——但不定义它们会做什么。那是 agent 自己的推理。

一个没有治理的 agent，就是后端架构里的 --dangerously-skip-permissions。我之前写过这个话题。这个 flag 意味着完全自治、零护栏——一开始好像没什么问题，直到 agent 写错数据库或者给错的人发了通知。

Simon Willison 把这叫做"致命三连"：不可信输入、特权访问、外部动作。当这三样东西在同一个系统里不受控地凑到一起，麻烦就来了。Agent 驱动的功能如果不小心，很容易三样全占。

这个模式真正让我睡不着的地方在这里：你的 agent 有 db.write 这个工具——等于拿到了生产库的完整写权限。一次错误的推理，就是几行垃圾数据。API 调用也一样，agent 拿着你的凭证去调外部服务，出了事是你要去解释。

所以我会把 agent 当成任何不可信的外部服务来对待。不要直接给它数据库连接。前面加一层 wrapper：按 schema 校验写入、强制行级权限、记录每一次操作——agent 想做什么，实际写了什么，谁触发的。默认连接只读，写入走单独的服务，只接受结构化输入。高风险操作进审批队列。每一次数据变更都要有审计日志，没有例外。agent 搞砸的时候，那份日志是你能追溯的唯一线索。

治理层要回答的是实打实的问题：记什么？什么操作执行前需要人工审批？agent 搞砸了怎么办？没有回滚方案，就不叫有治理。

边界问题

"agent as feature"架构里最难的设计问题：agent 决定什么，确定性代码处理什么？这条线画在哪？

不是所有东西都适合交给 agent。认证、计费、数据库迁移——这些必须确定性。你必须能审计，能精确预测行为。

在这些关键路径上，AI 可以辅助，但不能做最终决策。AI 是工具，能让你的工作更轻松；但对于那些有现实后果、不容有失的决策，不该让 AI 拍板。最重要的事情，永远要有人把关。

CockroachDB 有篇文章说得好："构建 agentic 应用，意味着主动把非确定性引入系统。"这是真实的代价。当你没法预测系统会做什么的时候，怎么测？传统单元测试不会告诉你 agent 的决策对不对。现在有 eval 框架了（LangSmith 做 trajectory-level 和 step-level 的评估），但这是一门大多数后端团队不熟悉的学科。而且经典分布式系统里的双写问题，也不会因为加了个 agent 就自动消失。

我大致把它分成三个区域：

Gartner 预计到 2027 年底，超过 40% 的 agentic AI 项目可能会被砍掉——成本失控、商业价值不清晰、风控不到位。我猜其中大部分被砍的项目，问题都出在边界画错了：要么给 agent 太多权限，非确定性变成了负担；要么给太少，agent 就只是个增加延迟的壳，好处一点没享受到。

为什么我觉得潜力是真的

"老办法也挺好"这种说法，在计算机不会推理的年代完全成立。我们搭了一棵又一棵复杂的决策树，因为那是把决策编码进软件的唯一方式。如果这个前提变了，架构也该跟着变。如果你手里有一个真正能理解意图、能围绕上下文做推理的系统，你不会用老办法去建它。

Srinivas Rao 对此强烈反对。他觉得多 agent 框架把对话和协调搞混了，称之为"规模化的架构愚蠢"。他的替代方案是：代码负责执行，LLM 负责决策，文件负责协调。他说 agent 不行，这一点我不同意。但关于协调，他确实说到了点子上——agent 之间不应该互相聊天，应该通过规范的协议调用工具。

工具链在快速成熟。MCP 给 agent 提供了标准的工具交互协议，Motia 把 agent 当成一等公民级别的后端构件。就在一年前，搭一个 agent 驱动的功能还像是把十几个库粘在一起然后祈祷它们能配合。现在已经有专门为这个场景设计的框架了。

然后是测试问题。以前功能靠单元测试、Playwright、集成测试来保证质量，但这些没法直接套到 agent 驱动的功能上。传统单元测试不会告诉你 agent 的推理靠不靠谱。我的想法是：用 skill 来测 skill。用一个 agent 去验证另一个 agent 的推理。这和 cross-family multi-AI review 的思路一样——不同模型抓不同盲点。架构变了，测试方法也得跟着变。

我打算在真实系统里做这件事，不只是写个 demo。我想看看当后端不再是"大脑"而是"护栏"的时候，到底会发生什么。

代价是真实的：更高的延迟，更高的单次请求成本，更难调试，而且目前还没有像 API 可用率那样被广泛认可的标准来衡量 agent 在生产环境的可靠性。团队在跟踪成功率、跑在线 eval、做人工 review——但还早。我不觉得这些是死胡同，它们是工程问题。难点在于规模化之后怎么做好。

我在关注什么

我最盯着的一个信号是 MCP 的采用率。如果 MCP 能成为 agent 与工具交互的标准协议——就像 HTTP 之于 Web——那这整个架构会变得简单很多。

推理成本也很关键。Agent 驱动的功能现在每次请求更贵，但这个差距在快速缩小。

然后是可靠性——这个问题目前还没有人真正回答。直到我们能像说"这个 API 有 99.9% 可用率"一样说出"这个 agent 驱动的功能有 99.5% 正确率"，大规模采用都会偏谨慎。Gartner 说到 2027 年 40%+ 的 agentic 项目会被砍？如果这些失败集中在某些特定模式上，那对我们其他人来说就是有价值的数据。

后端不会消失。它从"执行逻辑"变成了"治理 agent 能做什么"。

我不知道这能不能适用于所有场景，大概率不行。但对于那些你花了好几个月写分支逻辑、却始终没真正表达出你想要什么的功能？那些才是有意思的地方。那是我愿意下注的地方。

我正在做这件事。踩了坑会分享。