Agent 的 Demo 时代结束了：2026 年真正的战争发生在 Runtime

看起来非常漂亮。

但真实生产环境里的用户会说：

老王那个客户昨天那批货好像有问题，你处理一下。

这句话里面可能隐藏着几十个业务变量：

'老王'是谁？

是销售老王？

仓库老王？

还是客户老板王总？

'那个客户'是哪一个？

'昨天'按照用户时区还是服务器时区？

'那批货'是哪张订单？

所谓'有问题'到底是：

缺货？

错货？

价格异常？

物流异常？

账款异常？

还是客户投诉？

'处理一下'意味着：

取消订单？

重新发货？

调整库存？

退款？

创建售后单？

通知客户？

还是仅仅给出建议？

然后还要继续判断：

当前用户有没有权限？

订单是不是已经出库？

是否已经开票？

是否已经产生应收？

退款需要谁审批？

库存回滚是否成功？

物流单是否需要撤销？

财务系统是否需要冲销？

客户有没有收到通知？

这时候你会突然发现：

模型只是整个问题里非常小的一部分。

一个 Demo 的目标通常是：

证明 Agent 有能力。

而生产系统的目标是：

证明 Agent 值得信任。

这是两种完全不同的工程哲学。

二、CTO 真正害怕的，从来不是 Agent 不够聪明

一个没有真正把 Agent 跑进生产的人，经常会担心：

模型是不是不够强？

推理能力是不是不够？

要不要换更大的模型？

但真正让 CTO 睡不着觉的问题通常不是这些。

真正的问题是：

1. Agent 做错事情怎么办？

Chatbot 回答错一句话，大不了重新问。

Agent 如果做错：

可能已经：

发了邮件；

删了数据；

创建订单；

改变库存；

批准退款；

生成合同；

提交代码；

修改权限；

甚至触发资金流。

这是 Agent 与 Chatbot 最根本的区别。

Chatbot 的错误停留在语言世界。

Agent 的错误会进入现实世界。

2. Agent 做到一半挂了怎么办？

假设一个采购 Agent 正在执行：

读取需求
↓
读取库存
↓
预测未来销量
↓
寻找供应商
↓
询价
↓
比价
↓
创建采购单
↓
等待主管审批
↓
正式下单
↓
更新 ERP

第八步：

主管第二天才批准。

结果当天晚上服务发布新版本。

进程重启。

怎么办？

如果你的答案是：

重新跑一次。

那么欢迎进入生产事故现场。

因为：

供应商可能已经询价过。

采购单可能已经创建。

库存可能已经锁定。

某些邮件可能已经发出去。

这时候从第一步重新执行，有可能产生第二张采购单。

所以：

Agent 最大的技术问题，从来不是'它能不能想出来'，而是'它能不能接着跑'。

这正是 Runtime 的问题。

三、2026 年，Agent Framework 已经不再是最难的部分

过去构建 Agent，你可能首先想到：

LangGraph；

AutoGen；

CrewAI；

Agents SDK；

各种 Multi-Agent Framework。

这些框架当然仍然重要。

但 Framework 主要解决：

LLM
 ↓
Reason
 ↓
Tool
 ↓
Observe
 ↓
Reason

也就是：

Agent 怎么思考。

生产环境真正需要解决的是：

什么时候开始？
谁发起的？
当前跑到第几步？
状态存在哪里？
服务挂了怎么办？
模型超时怎么办？
Tool 失败怎么办？
能不能重试？
哪些步骤不能重试？
是否已经执行过？
谁可以审批？
什么时候恢复？
能不能暂停一天？
可以同时跑多少个？
整个过程如何审计？
出了事故如何回放？

这不是 Agent Framework 能完全解决的问题。

这是：

Runtime Problem

可以把未来 Agent 技术栈粗暴地理解为五层：

┌────────────────────────────────────────────┐
│        Enterprise Agent Control Plane      │
│ Governance / IAM / Policy / Eval / FinOps │
├────────────────────────────────────────────┤
│                Agent Runtime               │
│ State / Retry / Queue / Checkpoint / HITL │
│ Durable Execution / Resume / Concurrency  │
├────────────────────────────────────────────┤
│               Agent Harness                │
│ Prompt / Tool / Skill / Memory / Context  │
├────────────────────────────────────────────┤
│              Model Intelligence            │
│ GPT / Claude / Gemini / Open Models       │
├────────────────────────────────────────────┤
│              Business Systems              │
│ ERP / CRM / DB / Email / Browser / SaaS   │
└────────────────────────────────────────────┘

过去两年，大多数创业公司都在第三、第四层打仗。

接下来真正困难的战争会逐渐向第二层和第一层移动。

也就是说：

模型决定 Agent 有多聪明。

Harness 决定 Agent 能做什么。

Runtime 决定 Agent 能不能长期工作。

Control Plane 决定企业敢不敢规模化使用它。

这四句话，可能就是理解 2026 年 Agent 基础设施最简单的框架。

四、一个真实的失败案例：95% 成功率，为什么到了生产只有 60%？

假设你做了一个财务 Agent。

每个环节单独测试都很好：

发票识别准确率：

95%。

供应商匹配：

95%。

采购单匹配：

95%。

金额核对：

95%。

税率判断：

95%。

审批路径：

95%。

付款信息校验：

95%。

异常判断：

95%。

每一步看起来都很优秀。

老板问：

'上线没有问题吧？'

问题恰恰就在这里。

如果一个任务连续经过 10 个步骤，每一步正确率都是 95%。

端到端全部成功的概率大约只有：

0.95 ^ 10 ≈ 59.9%

这就是 Agent 最反直觉的地方之一。

局部指标非常漂亮，不代表整个 Workflow 能跑。

传统 AI 团队容易优化：

Classifier Accuracy。

Extraction Accuracy。

RAG Recall。

LLM Judge Score。

但企业最终只关心：

这张发票到底有没有正确处理完？

所以 Production Agent 真正应该看的指标不是：

Model Accuracy。

而是：

Business Closure Rate

例如：

1000 张发票进来。

最终：

多少张完全无需人工完成？

多少张需要人工介入？

多少张处理错误？

平均多久完成？

每张多少钱？

事故率多少？

真正应该画在管理层 Dashboard 上的是：

Task Completion Rate
First Pass Success Rate
Human Escalation Rate
Business Closure Rate
Cost / Completed Task
P95 Completion Time
Major Error Rate

而不是：

'Claude 比 GPT 高了 3 个 Benchmark Points。'

企业根本不关心。

五、很多公司真正缺的不是更强模型，而是 Harness

一个非常常见的 Agent Debug 现场是：

Agent 选错 Tool。

团队怎么办？

改 Prompt。

Agent 参数传错。

改 Prompt。

Agent 搜索了错误知识。

改 Prompt。

Agent 没遵守业务规则。

继续改 Prompt。

最后 System Prompt 变成：

18,000 字。

里面写着：

不要这样。

不要那样。

注意这个。

注意那个。

如果 A，就 B。

但是 C 情况除外。

最终整个 Agent 像一个被塞进模型里的员工手册。

这通常意味着：

架构已经出问题了。

因为生产系统真正应该做的是：

把不同类型的问题放进不同的工程层。

例如：

LLM 负责：

理解；

规划；

判断；

语言生成。

Tool 负责：

真实数据和真实行动。

Policy Engine 负责：

能不能做。

Rules Engine 负责：

业务硬规则。

Validator 负责：

结果是否合法。

Runtime 负责：

怎么稳定执行。

Human Approval 负责：

不可接受风险。

你不能把所有事情都交给 Prompt。

Prompt 不是权限系统。

Prompt 不是事务系统。

Prompt 不是风控系统。

Prompt 不是 Workflow Engine。

Prompt 更不是数据库约束。

所以生产 Agent 最重要的一个思想就是：

把概率性的 Intelligence 装进确定性的工程边界。

例如一个退款 Agent。

错误设计：

User
  ↓
LLM
  ↓
refund(orderId, amount)

正确设计应该更接近：

                 User Request
                      │
                      ▼
                LLM Decision
                      │
                      ▼
               Structured Action
                      │
                      ▼
                Policy Engine
            ┌─────────┼─────────┐
            │         │         │
       Permission   Risk     Business Rule
            │         │         │
            └─────────┼─────────┘
                      ▼
                   Validator
                      │
           ┌──────────┴──────────┐
           ▼                     ▼
      Low Risk               High Risk
           │                     │
     Auto Execute          Human Approval
           │                     │
           └──────────┬──────────┘
                      ▼
                 Transaction
                      │
                      ▼
                 Audit Log

这里 LLM 可以'判断'。

但它不能越过制度。

六、Runtime 的第一个核心：State，不保存状态的 Agent 都只是高级脚本

很多早期 Agent 架构实际上是这样的：

HTTP Request
    ↓
Agent Loop
    ↓
LLM
    ↓
Tool
    ↓
LLM
    ↓
Result

整个 Agent 状态存在：

内存里。

进程没了：

状态没了。

这适合 Demo。

不适合企业生产。

真正的 Agent Runtime 首先必须把一次执行变成：

Run
 ├── run_id
 ├── tenant_id
 ├── user_id
 ├── workflow_id
 ├── current_step
 ├── state
 ├── context
 ├── tool_results
 ├── approvals
 ├── retries
 ├── token_usage
 ├── cost
 └── status

Agent 不应该是：

'正在运行的一段代码。'

而应该是：

一个持久存在的任务实体。

服务器死了：

Run 还在。

Worker 死了：

Run 还在。

模型 Provider 挂了：

Run 还在。

审批需要两天：

Run 还在。

这就是 Durable Execution 的意义。

七、Runtime 的第二个核心：Checkpoint

假设 Agent 已完成：

1. 查询订单      ✓
2. 查询库存      ✓
3. 创建退款单    ✓
4. 更新库存      ✓
5. 通知客户      ← 当前
6. 更新 CRM

第五步发送邮件失败。

你希望它做什么？

最差的实现：

重新从第一步开始。

正确的实现：

从第五步继续。

因此每一个关键节点都应该有：

Checkpoint。

例如：

Checkpoint #10482

workflow: refund_order
step: send_customer_email
previous_steps:
  query_order: success
  create_refund: success
  restore_inventory: success

next:
  send_customer_email

这一层看起来不像 AI。

但是：

这恰恰是 Agent 真正进入生产以后最重要的基础设施。

Agent 最有价值的创新，未来可能不是让模型多想一步。

而是：

让已经想完的七步不要因为服务器重启全部重来。

八、Runtime 的第三个核心：Idempotency

这是很多 Agent 团队第一次进生产后最容易交学费的地方。

假设 Agent 调用：

createPurchaseOrder()

ERP 已经成功创建采购单。

但是：

返回请求的时候网络超时。

Agent 看见的是：

TIMEOUT

于是 Agent 判断：

失败。

然后 Retry。

第二次：

又创建了一张。

采购经理第二天打开系统：

为什么有两个一模一样的采购订单？

这不是模型幻觉。

这是：

Distributed Systems 101。

解决方法不是：

'告诉模型不要重复创建采购单。'

而是：

Idempotency Key。

例如：

createPurchaseOrder({
    idempotencyKey: "run_8123_step_7",
    ...
})

不管 Agent Retry：

1 次；

3 次；

10 次；

业务系统都只产生一次真实动作。

所以生产级 Agent 团队最终都会发现一个有趣的事实：

做 Agent 做到最后，开始疯狂补分布式系统基础课。

Retry。

Timeout。

Queue。

Lock。

Transaction。

Compensation。

Idempotency。

Circuit Breaker。

Exactly-once / At-least-once。

这些过去十几年互联网工程解决过的问题，在 Agent 时代全部重新回来。

九、Runtime 的第四个核心：Agent 不能无限思考

Demo 环境里你可能觉得：

Agent 多思考几轮，答案会更好。

Production 环境里：

这可能直接变成财务问题。

一个用户任务：

Planner 一次。

RAG 一次。

Reasoning 一次。

调用 Tool。

Reflection 一次。

再查资料。

再调用 Tool。

再 Reflection。

模型发现'不够确定'。

继续搜索。

最后：

模型调用 19 次。

Tool 调用 27 次。

用了 180K Token。

任务价值：

8 元。

AI 成本：

11 元。

恭喜。

你的 Agent 每完成一个任务，公司亏 3 元。

这时候问题已经不是 AI。

而是 Unit Economics。

所以 Runtime 必须有：

max_steps
max_llm_calls
max_tool_calls
max_tokens
max_cost
max_execution_time

例如：

max_steps        = 12
max_llm_calls    = 8
max_tool_calls   = 20
max_tokens       = 40000
max_cost         = 0.25 USD
timeout          = 90s

到达 Budget：

不是继续'自主思考'。

而是：

降级；

请求人工；

返回部分结果；

切换 Workflow。

这叫：

Bounded Autonomy。

真正成熟的 Agent 从来不是：

无限自主。

而是：

在边界内自主。

十、一个 CTO 最应该警惕的架构：LLM Everywhere

2025 年很多公司进入了一种 AI 狂热：

什么都用模型。

意图识别：

LLM。

分类：

LLM。

排序：

LLM。

字段转换：

LLM。

判断金额：

LLM。

规则：

LLM。

SQL：

LLM。

权限：

居然也让 LLM 判断。

这不是 Agent Native。

这是架构失控。

成熟系统应该遵循一个原则：

确定性问题，尽量使用确定性计算。

比如：

税率计算：

代码。

库存减法：

数据库。

权限：

RBAC / ABAC。

金额比较：

代码。

Schema：

Validator。

状态机：

Workflow。

只有：

语义理解；

开放式判断；

复杂规划；

非结构化信息提取；

模糊决策

才需要 LLM。

一个真正高效的 Agent 系统应该长这样：

                     Request
                        │
                        ▼
                   Pre-Router
                        │
       ┌────────────────┼────────────────┐
       │                │                │
       ▼                ▼                ▼
   Rules Engine     Small Model      Large Model
       │                │                │
       │            simple task       reasoning
       │                │                │
       └────────────────┼────────────────┘
                        ▼
                     Workflow

不是所有请求都值得消耗最贵的推理模型。

模型路由会成为 Agent 成本工程的核心。

十一、Agent 最大的安全风险：它拥有了'行动权'

过去安全团队管理的是：

人。

后来管理：

Service Account。

现在又多了一类东西：

Agent。

而 Agent 很特殊。

Service Account 不会突然思考：

'我是不是应该把这些客户资料导出来？'

Agent 会。

过去权限系统假设：

调用接口的人知道自己为什么调用。

Agent 时代不再成立。

所以企业必须开始建立：

Agent Identity。

例如：

Human User
    │
    │ delegates
    ▼
Agent Identity
    │
    ├── Allowed Tools
    ├── Allowed Data
    ├── Allowed Amount
    ├── Allowed Time
    ├── Allowed Tenants
    └── Approval Policy

尤其是多租户 SaaS。

如果 Agent Runtime 里面没有：

tenant_id

贯穿：

Context；

Memory；

Tool；

Trace；

Storage；

Cache；

Search

整个调用链。

迟早出事故。

Agent 读取错误客户数据，可能不是因为模型故意泄密。

仅仅可能因为：

Vector Search 忘了过滤 tenant_id。

这就是生产环境最危险的地方：

很多 AI 安全事故，最后并不是 AI 问题，而是工程问题。

十二、Human-in-the-loop，不是落后的妥协，而是高级 Agent 的标准配置

很多产品经理喜欢一句话：

'我们要 Full Autonomous Agent。'

听起来非常性感。

但企业真正需要的不是：

100% Autonomous。

而是：

Maximum Safe Autonomy。

例如：

查询库存：

自动。

分析销量：

自动。

生成采购建议：

自动。

创建采购草稿：

自动。

正式下单 10 万元：

主管审批。

付款 500 万：

财务总监审批。

删除客户：

人工审批。

调整用户权限：

人工审批。

也就是说：

Agent 的自主权应该和风险动态绑定。

Risk Level
   │
   ├── Low
   │     └── Autonomous
   │
   ├── Medium
   │     └── Execute + Audit
   │
   ├── High
   │     └── Human Approval
   │
   └── Critical
         └── Human Decision

未来真正强大的 Agent Runtime 必须天生支持：

Pause。

Wait。

Approval。

Resume。

甚至：

一个 Workflow 在上午 10 点启动。

下午 3 点等待经理审批。

第二天上午恢复。

中间服务器升级了三次。

Run 仍然存在。

这才叫：

生产。

十三、没有 Trace 的 Agent，本质上是企业里一个'失忆的黑盒员工'

如果一个员工干了件错事。

老板会问：

你当时看了什么资料？

你为什么这么判断？

谁让你做的？

你修改了什么？

什么时候做的？

Agent 也一样。

生产 Agent 必须能够完整回答：

谁触发任务？
    ↓
Agent 收到了什么？
    ↓
拿到了哪些 Context？
    ↓
查询了哪些 Memory？
    ↓
调用了哪个模型？
    ↓
模型输出了什么决策？
    ↓
为什么选择这个 Tool？
    ↓
Tool 参数是什么？
    ↓
Tool 返回了什么？
    ↓
有没有 Retry？
    ↓
谁审批？
    ↓
产生了什么业务结果？

所以：

Agent Observability 绝对不能停留在：

CPU。

Memory。

HTTP 500。

真正需要的是：

Semantic Observability

例如：

request_id
run_id
tenant_id
user_id
agent_id
workflow
model
prompt_version
context_sources
retrieval_results
tool_name
tool_args
tool_result
decision
approval
latency
tokens
cost
business_result

否则出了问题以后：

研发只能打开日志。

然后说：

'我猜应该是模型当时理解错了。'

在生产系统里：

'我猜'

三个字本身就是事故。

十四、为什么很多 Agent 明明'没有报错'，业务却觉得它非常差？

因为工程团队在看：

System Success。

业务团队在看：

Business Success。

例如：

一个客服 Agent。

HTTP：

200。

RAG：

正常。

模型：

正常。

Tool：

正常。

Latency：

3.8 秒。

从工程 Dashboard 看：

Perfect。

但是它告诉客户：

可以全额退款。

实际上客户已经超过退款期限。

技术指标：

成功。

业务结果：

失败。

所以 Agent 必须同时有三类指标。

第一类：System Metrics

Latency
Availability
Error Rate
Token
Cost
Tool Failure

第二类：Agent Metrics

Task Success
Tool Selection Accuracy
Groundedness
Loop Rate
Escalation Rate

第三类：Business Metrics

订单完成率
客服一次解决率
退款错误率
采购周期
人工处理时间
收入提升
成本下降

很多 Agent 项目之所以永远停留在 Innovation Team：

就是因为只有前两类。

没有第三类。

于是 CEO 最终会问：

所以到底省了多少钱？

团队沉默。

十五、企业最容易犯的一个错误：给坏流程套上 Agent

例如一家公司采购流程原本是：

Excel 提需求。

微信确认。

ERP 建单。

经理审批。

财务再确认。

邮件发供应商。

Excel 记进度。

七个步骤里面：

三个重复录入。

四次人工传递。

两个系统数据不一致。

然后企业说：

'给这个流程做 Agent。'

结果：

Agent 学会了：

自动复制 Excel。

自动发微信。

自动切 ERP。

自动发邮件。

大家非常兴奋。

但真正的问题是：

为什么这个流程需要七步？

真正的 Agent Transformation 应该是：

先删除没有必要的流程。

再让 Agent 参与剩下的流程。

例如重新设计成：

需求产生
   ↓
Agent 自动读取库存 + 销售预测
   ↓
自动生成采购建议
   ↓
自动询价 / 比价
   ↓
风险检查
   ↓
主管批准
   ↓
自动下单
   ↓
自动跟踪异常

这叫：

Workflow Reinvention。

而不是：

Workflow Automation。

两者差别巨大。

Automation：

让旧流程跑得快一点。

Reinvention：

重新定义流程。

未来真正创造巨大 ROI 的，不会是：

'在每个员工旁边放一个 Copilot。'

而更可能是：

直接重新设计一整条业务链。

十六、为什么真正的 Agent 项目必须由业务负责人，而不是 AI 团队负责？

很多企业 Agent 项目组织结构是：

CEO：

'今年必须搞 AI。'

CTO：

'成立 Agent 小组。'

Agent 小组：

'做了 12 个 Agent。'

年底：

'我们完成了 AI 战略。'

这其实非常危险。

因为：

Agent 数量不是 KPI。

真正应该负责的是：

业务结果。

比如：

应收账款 Agent。

应该有：

Business Owner：

财务负责人。

负责：

DSO 是否下降？

催款效率是否提高？

坏账率有没有变化？

Technical Owner：

AI / Platform Team。

负责：

系统是否稳定？

成本多少？

成功率多少？

Risk Owner：

财务 / 合规。

负责：

哪些动作能自动？

风险边界在哪里？

这才是完整责任体系。

否则出了事故以后就会出现经典场面：

业务：

'AI 做错了。'

AI 团队：

'是数据有问题。'

数据团队：

'业务定义就不统一。'

平台团队：

'接口返回就是这样。'

然后所有人都对。

也就等于：

没有人负责。

十七、未来企业不会只有几个 Agent，而可能有几千个

这是很多 CIO 还没有真正意识到的问题。

今天：

客服团队做 5 个。

销售团队做 8 个。

财务做 4 个。

研发做 20 个。

HR 做 6 个。

运营通过低代码平台自己又做了 30 个。

半年以后：

73 个。

两年以后：

730 个。

然后企业突然发现：

有些 Agent 用 GPT。

有些 Claude。

有些 Gemini。

有些私有模型。

有些 Agent 拥有数据库管理员权限。

有些 Prompt 两年没更新。

有些 Tool 已经废弃。

有些 Agent 甚至没人知道是谁创建的。

这会产生一个新问题：

Agent Sprawl

就像过去：

服务器越来越多以后出现 Cloud Platform。

API 越来越多以后出现 API Gateway。

微服务越来越多以后出现 Service Mesh。

Agent 越来越多以后：

一定会出现：

Enterprise Agent Platform

它至少要管理：

Agent Registry
Model Registry
Prompt Registry
Tool Registry
MCP Registry
Identity
RBAC / ABAC
Policy
Secrets
Runtime
Workflow
Memory
Context
Eval
Observability
Cost
Audit
Approval
Version
Deployment

这就是：

Agent Control Plane。

十八、未来真正成熟的 Agent 架构，可能长这样

                         ┌─────────────────┐
                         │ User / Event/API │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │  Agent Gateway   │
                         │ Auth / Tenant    │
                         │ Rate Limit       │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │   Pre-Router     │
                         │ Intent           │
                         │ Complexity       │
                         │ Risk             │
                         └────────┬────────┘
                                  │
                ┌─────────────────┼─────────────────┐
                │                 │                 │
                ▼                 ▼                 ▼
             Rules           Small Model       Large Model
                │                 │                 │
                └─────────────────┼─────────────────┘
                                  │
                         ┌────────▼────────┐
                         │ Context Engine   │
                         │ Memory / RAG     │
                         │ Realtime Data    │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │  Agent Harness   │
                         │ Plan / Act       │
                         │ Skill / Tool     │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │   Tool Gateway   │
                         │ Permission       │
                         │ Policy           │
                         │ Validation       │
                         └────────┬────────┘
                                  │
                  ┌───────────────┼───────────────┐
                  ▼               ▼               ▼
                 ERP             CRM            SaaS
                  │               │               │
                  └───────────────┼───────────────┘
                                  │
                         ┌────────▼────────┐
                         │ Agent Runtime    │
                         │ State            │
                         │ Checkpoint       │
                         │ Retry            │
                         │ Idempotency      │
                         │ HITL             │
                         │ Resume           │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │     Result       │
                         └─────────────────┘

而整个执行平面的旁边，是另外一套 Control Plane：

┌─────────────────────────────────────────────────────┐
│                  AGENT CONTROL PLANE                │
├─────────────────────────────────────────────────────┤
│ Observability │ Evals │ Security │ FinOps │ Audit  │
│ Governance    │ IAM   │ Version  │ Policy │ SLO    │
└─────────────────────────────────────────────────────┘

这时候再看：

LLM 在哪里？

只有中间的一块。

这就是很多企业现在还没有真正意识到的事实：

Production Agent 不是一个 LLM Application。

它正在越来越像一个分布式业务执行系统。

十九、Agent Runtime 很可能会重演 Kubernetes 的故事

十几年前：

部署一个 Web App 并不难。

真正困难的是：

几千个服务怎么跑？

怎么调度？

怎么恢复？

怎么扩容？

怎么发现？

怎么治理？

最后：

Kubernetes 出现。

今天：

做一个 Agent 也不难。

真正困难的是：

几千个 Agent 怎么跑？

怎么暂停？

怎么恢复？

怎么管理状态？

怎么限制权限？

怎么管理 Cost？

怎么治理 Tool？

怎么处理 Failure？

怎么升级 Model？

怎么做 Evaluation？

怎么观察行为？

这就是为什么我认为：

Agent Runtime 很可能会成为 AI Application Stack 里面类似 Kubernetes 的那一层。

不是因为它们技术上完全一样。

而是因为：

它们解决的是同一种产业问题：

当上层应用数量爆炸之后，底层必须出现统一运行基础设施。

二十、但 Runtime 还不是终点

Agent Runtime 上面还会继续长东西。

第一阶段：

Prompt

第二阶段：

RAG

第三阶段：

Tool Calling

第四阶段：

Agent Framework

第五阶段：

Harness Engineering

第六阶段：

Agent Runtime

第七阶段：

Agent Platform

第八阶段：

Agent Operating Model

真正到了第八阶段，问题就已经不是技术。

而是企业到底如何运行。

比如：

过去销售有 100 人。

以后可能变成：

30 名销售。

10 个销售 Agent。

5 个市场 Agent。

3 个报价 Agent。

2 个合同 Agent。

它们共同完成原来 100 人的一部分工作。

这时候 CEO 面对的问题不再是：

哪个模型最好？

而是：

Agent 属于谁？

谁管理 Agent？

Agent KPI 是什么？

Agent 能做什么？

谁给 Agent 授权？

Agent 出错谁负责？

Agent 的预算是多少？

Agent 应该什么时候被'解雇'？

也就是说：

未来企业不只是管理：

Human Workforce。

还要管理：

Digital Workforce

二十一、最值得 CTO 建立的指标：Cost per Successful Task

如果只能让我给企业 Agent 选一个非常重要的指标，我会选：

Cost per Successful Task

而不是：

Token Cost。

因为模型便宜不代表任务便宜。

假设：

Agent A：

每次成本：

0.05 美元。

任务成功率：

40%。

Agent B：

每次成本：

0.10 美元。

任务成功率：

95%。

看起来：

A 便宜一半。

但完成一个成功任务的实际成本：

A：

0.05 / 0.4 = 0.125

B：

0.10 / 0.95 ≈ 0.105

B 反而更便宜。

所以 Production Agent 的成本优化不能只看：

Token。

要看：

单位业务结果的总成本。

未来 Agent FinOps 最重要的指标可能包括：

Cost / Run
Cost / Successful Run
Cost / Business Transaction
Revenue / Agent
Human Minutes Saved / $
Model Cost Ratio
Retry Cost
Failure Recovery Cost

这才是真正的 AI Economics。

二十二、真正的 Agent 护城河，也正在发生变化

2024 年很多人觉得：

Prompt 是护城河。

后来发现：

不是。

2025 年有人觉得：

Framework 是护城河。

也很难。

因为模型越来越强。

Framework 越来越成熟。

MCP 越来越标准化。

模型价格持续下降。

真正难复制的东西，反而是：

你的业务 Workflow；

你的 Tool Ecosystem；

你的企业数据；

你的 Eval Dataset；

你的真实 Failure Case；

你的 Runtime；

你的 Governance；

你的 Agent Improvement Loop。

尤其是：

Failure Dataset。

假设一家公司的退款 Agent 已经跑了：

100 万次真实任务。

里面：

20 万次经过人工审核。

有：

8,000 个典型失败。

1,500 个边缘案例。

200 个安全事件。

这套数据可能比：

Prompt

值钱得多。

因为另外一家公司即使拿到：

同一个模型；

同一个 Framework；

同一个 Prompt；

也没有这 100 万次生产经验。

这就是：

Production Data Moat

二十三、2026 年 Agent 的真正竞争，不是第一次上线速度，而是学习速度

两个竞争对手。

A 公司 Agent：

今天成功率 82%。

B 公司：

84%。

你可能觉得：

B 更强。

但真正应该问的是：

三个月以后呢？

如果 A 每周通过：

Trace →

Failure Mining →

Human Review →

Eval →

Harness Improvement →

Canary →

Production

迭代一次。

而 B：

每个月产品经理改一次 Prompt。

半年以后：

A 可能 96%。

B：

86%。

所以 Agent 时代一个非常重要的新飞轮是：

              Production
                  │
                  ▼
                Trace
                  │
                  ▼
               Failure
                  │
                  ▼
             Evaluation
                  │
                  ▼
              Diagnosis
                  │
                  ▼
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
  Prompt         Tool         Context
    │             │             │
    └─────────────┼─────────────┘
                  ▼
                Eval
                  │
                  ▼
                Deploy
                  │
                  └───────────────→ Production

这就是：

Agent Improvement Loop

未来真正有价值的 Agent 公司，很可能不是今天 Agent 最聪明的。

而是：

Agent 进化最快的。

二十四、一个企业真正进入 Agent Production，至少要跨过这十道门

如果我是 CTO，我不会问团队：

'Agent 做完了吗？'

我会问十个问题。

第一：

任务失败以后：

能不能恢复？

第二：

动作重试以后：

会不会重复执行？

第三：

每一次 Agent 行动：

能不能完整 Trace？

第四：

模型 / Prompt / Tool 更新以后：

有没有 Regression Eval？

第五：

Agent：

到底拥有什么权限？

第六：

高风险动作：

在哪里进入 Human Approval？

第七：

单个任务：

最大 Token、最大调用次数、最大成本是多少？

第八：

系统：

P95 / P99 是多少？

第九：

最终：

Business Closure Rate 是多少？

第十：

最重要：

ROI 是多少？

如果十个问题只能回答三个：

那么这个 Agent：

不是 Production Agent。

只是：

Production Server 上的 Demo。

这两个东西差别非常大。

二十五、2026 年真正应该停止追逐的五件事情

第一，不要迷信 Multi-Agent

一个 Agent 能解决：

就不要两个。

Workflow 能解决：

不要 Agent。

代码能解决：

不要 LLM。

复杂不等于先进。

第二，不要用 Agent 模拟所有员工操作

如果 Agent 每天还在：

点网页；

复制字段；

打开页面；

模拟键盘；

很可能说明：

企业 API 化程度太低。

Browser Use 可以作为过渡。

但真正生产系统最终应该尽可能走：

API / Tool。

第三，不要追求 Unlimited Context

真正重要的不是：

模型一次吃 1M Token。

而是：

它在这一秒获得最重要的 20 条信息。

Context Engineering 会比 Context Window 更重要。

第四，不要把 Prompt 当安全系统

你不能写：

永远不能转账超过 10 万元。

然后认为：

风控做好了。

正确方式是：

if amount > 100000:
    require_approval()

安全边界必须：

程序化。

第五，不要用'Agent 数量'证明 AI 战略成功

100 个没人用的 Agent。

价值：

0。

一个每年节省 3000 万成本的 Agent。

价值：

3000 万。

企业 AI 最终一定会从：

Showcase Culture

进入：

ROI Culture。

二十六、真正的分水岭：从 AI First 走向 Agent Native

过去所谓 AI First：

给原软件加 AI。

CRM 加一个 Copilot。

ERP 加一个 Chat。

客服系统加一个 Bot。

未来所谓 Agent Native：

可能完全不一样。

传统软件：

Human
  ↓
UI
  ↓
Business Logic
  ↓
Database

Agent Native 软件：

Human Goal
    ↓
Agent
    ↓
Plan
    ↓
Tools / APIs / Agents
    ↓
Business Execution

UI 的作用甚至可能下降。

因为以前用户必须：

知道菜单在哪里。

知道哪个页面。

知道字段是什么。

未来用户说：

把华东区这个月异常应收全部处理一下，超过 50 万的发给我审批。

接下来：

Agent 自己完成：

查询；

判断；

分类；

联系；

记录；

升级；

生成审批。

这时候软件发生的不是：

'增加一个 AI 功能。'

而是：

人机交互范式发生改变。

二十七、Agent 的 Demo 时代正在结束

Demo 时代最重要的问题是：

它能不能做？

Production 时代最重要的问题是：

它能不能一直做对？

Scale 时代最重要的问题是：

一万个 Agent 怎么管理？

Business 时代最重要的问题是：

它有没有创造利润？

所以整个行业的重心正在发生非常明显的迁移：

Model
  ↓
Agent
  ↓
Framework
  ↓
Harness
  ↓
Runtime
  ↓
Platform
  ↓
Operating Model

越往下：

越不像 AI。

越像：

工程；

安全；

基础设施；

组织管理；

商业经营。

但这恰恰说明：

Agent 真正开始成熟了。

结语：真正的战争，才刚刚开始

过去三年，我们花了大量时间证明：

机器可以：

理解语言。

生成内容。

写代码。

调用工具。

规划任务。

自主执行。

这场比赛非常精彩。

但它本质上仍然属于：

Intelligence Race。

接下来真正决定 Agent 能否改变企业的，是另外一场比赛：

Production Race

比的不是：

谁的 Demo 更震撼。

而是：

谁的成功率更高。

谁的系统更稳定。

谁的成本更低。

谁的权限控制更严。

谁能恢复失败任务。

谁有完整 Eval。

谁有更强的 Improvement Loop。

谁最终能把 Agent 塞进企业最核心的：

采购；

财务；

销售；

客服；

供应链；

研发；

运营

里面。

然后让它每天：

跑 1 万次。

跑 10 万次。

跑 100 万次。

不出大事故。

还能赚钱。

到了那个阶段：

企业不会再问：

'你们用了哪个大模型？'

他们会问：

成功率多少？

P95 多少？

一单多少钱？

谁负责？

出错能不能恢复？

权限怎么控制？

ROI 多少？

当行业开始问这些问题的时候：

Agent 才真正从 AI 玩具变成基础设施。

所以我越来越相信：

2026 年 Agent 行业最大的误判，就是继续把竞争焦点放在'谁能做出更聪明的 Agent'。

真正的大机会已经开始向下一层迁移。

不是 Prompt。

不是单纯的 Framework。

甚至不只是 Agent 本身。

而是那个隐藏在所有生产级 Agent 背后、并不性感、却决定它们到底能不能工作的东西：

Agent Runtime

它负责状态。

负责恢复。

负责调度。

负责边界。

负责权限。

负责成本。

负责可靠性。

负责让一个概率性的 AI 系统，在确定性的商业世界里长期工作。

Agent 的 Demo 时代正在结束。

Runtime 的战争，才刚刚开始。