2026年最危险的，不是不会写代码，而是不会设计 Agent 工作流

上个月，我们给团队接了一个“代码评审 Agent”。

Demo 那天很惊艳：它能读 diff、能提重构建议、还能自动生成 review 评论。三天后，我们把它下线了。

不是模型突然变笨，而是它在最关键的一步不断翻车： 该谨慎时自信满满，该给证据时只给结论，该升级给人时硬着头皮继续执行。

那一刻我意识到，2026 年真正危险的能力断层，不是“你会不会写代码”，而是“你会不会设计 Agent 工作流”。

先说一个我看到的信号

这几天我刷 GitHub，有两个现象非常明显：

• 框架在飞快迭代：LangChain langchain-core==1.2.26、LangGraph 1.1.6、LlamaIndex v0.14.20、vLLM v0.19.0、Transformers v5.5.0，发布时间几乎都挤在 4 月初。
• 新项目的关注点在变化：比起“更会聊天的模型”，大家更关心“可执行、可回滚、可协作”的 Agent 工程能力。

这说明一件事： 模型能力正在变成基础设施，真正拉开差距的是流程设计能力。

为什么“会写代码”不够了

过去我们做软件，默认逻辑是确定性的：输入 A，得到 B。 现在接入 Agent 后，系统里多了一个概率节点：它有时正确，有时离谱，而且离谱时往往很像正确。

这意味着工程挑战变了：

你要设计的，不再只是函数调用链，而是一个“会犯错的执行体”的活动范围。

换句话说，代码能力解决“怎么做”； 工作流能力解决“做错了怎么办”。

Agent 工作流到底在设计什么

我现在把 Agent 工作流拆成四层：

1. 任务状态层：每一步都有明确状态（待执行、执行中、成功、失败、需人工确认），不能只靠一段 prompt 一把梭。
2. 决策路由层：不同任务走不同路径，简单任务直达，风险任务必须升级或二次验证。
3. 工具约束层：Agent 不是“想调什么就调什么”，每个工具要有输入输出契约、超时、重试和幂等策略。
4. 观测评估层：全链路日志、失败分类、回放样本、成本统计。没有观测，优化就是玄学。

很多团队不是模型不行，而是这四层有两层是空的。

那次“最后一步翻车”，我们怎么修

最开始我们的流程是这样的：

• 把 PR diff 丢给 Agent
• 让它输出 review 建议
• 自动回写到代码平台

看起来顺，实际上风险极高。因为“输出”那一步没有证据门槛。

后来我们改成了五步：

• 第一步：先做变更分类（语法改动、逻辑改动、依赖改动、接口改动）
• 第二步：再做风险评分（低/中/高）
• 第三步：只在需要时调用外部工具（测试日志、历史缺陷、相关文件）
• 第四步：生成“带证据的建议”，每条建议必须附上定位依据
• 第五步：高风险建议默认不自动提交，进入人工确认

改完之后，最明显的变化不是“它更聪明了”，而是“它更可控了”。

可控，才是工程系统里真正的智能。

我越来越确定的一件事

2026 年之后，团队会出现一个新分层：

• 只会写 prompt 的人，在做“效果演示”；
• 能设计工作流的人，在做“生产系统”。

前者能跑出一个漂亮 demo，后者能扛住凌晨两点的报警。

如果你今天就在做 AI 应用，我的建议不是“再调 20 版提示词”， 而是先问自己三个问题：

• 你的 Agent 失败后会停在哪里？
• 谁可以接管？接管时能看到什么上下文？
• 这次失败会不会在一周后重复出现？

这三个问题，决定了你的系统是在“表演智能”，还是“交付智能”。

结尾

“不会写代码”会让你慢一点， “不会设计工作流”会让你在关键时刻直接失控。

下一个阶段，最值钱的工程能力，不是把模型接进来， 而是把模型关进一个可被治理的流程里。

这是我最近最深的体感。

你们团队现在的 Agent，属于“能跑”，还是“能扛事”？