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

**Summary:** Gartner 预测到 2026 年，40% 的企业应用会嵌入 AI 智能体。Agent as Feature 模式用推理型智能体替代确定性控制器。本文探讨这对后端架构意味着什么，以及为什么这个潜力是真实的。

- Canonical: https://markhuang.ai/zh/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-03-10
- Section: AI 与 LLM
- Tags: AI 智能体, 后端架构, Agentic AI, 软件架构
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

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

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

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

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

![Agent as Feature](https://cdn.markhuang.ai/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic/hero.webp)

*Agent as Feature*

## 传统后端就是一棵决策树

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

```text
Request → Router → Controller → Service → Database → Response
```

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

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

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

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

但如果计算机会推理呢？

![传统流程 vs Agent 流程](https://cdn.markhuang.ai/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic/traditional-vs-agent-flow.zh-CN.webp)

*传统流程 vs Agent 流程*

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

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

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

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

代码的样子变了：

```text
// 传统写法：从收据里提取报销字段
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 校验、错误处理。但代码确实不一样了——你告诉它你要什么，而不是一步步写清楚怎么做。

> **Tip:**
>
> AI 负责推理，确定性代码负责治理。后端没有消失，只是换了职责。

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

## Webhooks + Agent 模式

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

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

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

![Webhooks + Agent 模式](https://cdn.markhuang.ai/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic/webhooks-agents-pattern.webp)

*Webhooks + Agent 模式*

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 被治理护栏包围](https://cdn.markhuang.ai/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic/governance-guardrails.webp)

*Agent 被治理护栏包围*

## 后端变成了治理层

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

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

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

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

> **Info:**
>
> Simon Willison 提出的 AI agent "致命三连"：不可信输入 + 特权访问 + 外部动作。任何没有对这三者做明确控制的 agent 驱动功能，都是安全隐患。很多 MCP server 是"凭感觉写的"，安全意识很薄弱。来源：[Korny Sietsma on martinfowler.com — Agentic AI Security](https://martinfowler.com/articles/agentic-ai-security.html)

这个模式真正让我睡不着的地方在这里：你的 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 就自动消失。

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

| 区域           | 举例                            | 原因                 |
| ------------ | ----------------------------- | ------------------ |
| **Agent 负责** | 自然语言理解、多步推理、动态路由、非结构化数据中的模式识别 | 模糊性本身就是功能，不是 bug   |
| **确定性代码**    | 财务计算、访问控制、数据完整性约束、合规规则        | 必须精确、可审计、可复现       |
| **混合**       | Agent 分类报销，确定性代码执行审批策略        | Agent 给建议，代码做校验和执行 |

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

> **Tip:**
>
> 一个简单的判断方法：如果这个任务你会希望有人严格按 checklist 来做，用确定性代码。如果你会希望有人根据情况灵活判断，那就是 agent 的活。

![边界图：Agent 领域 vs 确定性领域](https://cdn.markhuang.ai/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic/boundary-map.webp)

*边界图：Agent 领域 vs 确定性领域*

## 为什么我觉得潜力是真的

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

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 能做什么"。

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

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

> **Info:**
>
> 延伸阅读：[Go Wombat 的 Agent as a Backend](https://gowombat.team/blog/posts/agent-as-a-backend)、[Dan Shipper 在 Every.to 的文章](https://every.to/chain-of-thought/agent-native-architectures-how-to-build-apps-after-the-end-of-code)、[InfoQ 关于执行引擎的报道](https://www.infoq.com/news/2025/10/ai-agent-orchestration/)、[Everworker.ai 的 webhooks 文章](https://everworker.ai/blog/connect-ai-agents-with-webhooks)、[Gartner 报告](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025)、[CockroachDB 谈非确定性](https://www.cockroachlabs.com/blog/agentic-applications-deterministic-foundations/)、[Fowler 谈 agentic 安全](https://martinfowler.com/articles/agentic-ai-security.html)。[Motia](https://www.motia.dev/) 也值得一看。