夜雨聆风引子：大约十年前，我还是软件架构师，同时兼着技术负责人，带团队做项目、开发系统。
2016年，我在知乎写过一篇《优秀的项目管理与糟糕的项目管理》。那个时候，我对程序员的要求很简单：专业，会干。
做Java的，要真正懂Java；做数据库的，要真正懂数据库；负责一个模块，就得有能力把它干下来。
后来，我的工作逐渐从软件架构走向集团业务领域架构，再到集团级企业架构。关注的问题也从“这个功能怎么实现”，变成了业务怎么划分、系统边界在哪里、数据怎么组织、不同系统之间应该是什么关系。
一晃接近十年，我已经很少真正写代码了。
但AI时代来了以后，我反而重新开始关注软件工程。近几年，我调研过不少智能体项目，其中一些还是“门面”案例。真正看进去以后，我发现很多项目的基本思路其实差不多：
用户提问 → 大模型识别意图 → 匹配场景 → 调用接口 → 按既定流程执行。
这种做法没有问题，也属于Agentic System的一种，而且对于流程明确、要求稳定的业务场景，往往还是更合适的做法。
但它让我开始思考一个问题：
如果绝大部分执行路径仍然是程序员提前设计好的，那么Agent到底改变了软件架构的哪一部分？
这个周末难得有空，我决定自己试一次。不是为了研究某个具体业务，而是想验证一种我认为更接近Agent本身特点的架构方式。
一、Agent与Workflow的分界：谁在决定下一步
先把一个问题说清楚。
Agent和Workflow都可以调用Tool。
查询数据库是Tool，解析Excel是Tool，调用企业内部系统接口也是Tool。
Tool本来就应该是提前开发好的、稳定的、确定性的能力。
真正的差别不在Tool，而在Tool上面的控制逻辑。
比如有三个工具：
Tool A：获取数据
Tool B：分析数据
Tool C：生成报告
如果程序员提前规定：
识别到某类需求 → 调A → 调B → 调C
那么它更接近Workflow。
如果Agent接到目标以后，先判断当前缺什么，调用A；看到A的结果以后，再决定调用B还是其他工具；发现信息不足，还可以调整原来的计划——这才更能体现Agent的特点。
Anthropic在《Building Effective AI Agents》中有一句非常清楚的定义：
“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
翻译过来就是：
Workflow，是通过预先定义好的代码路径来编排大模型和工具的系统。
而Anthropic对Agent的描述恰恰相反：由LLM动态控制自己的执行过程和工具使用。
OpenAI在《A Practical Guide to Building Agents》中也有一句很直接的话：
“Applications that integrate LLMs but don’t use them to control workflow execution … are not agents.”
也就是说，仅仅在应用里接入LLM还不够，LLM需要真正参与Workflow的执行和决策。 OpenAI随后给出的Agent特征之一，就是模型能够根据当前任务状态动态选择合适的工具。
所以判断一个系统的Agent程度，我觉得可以先问一个很简单的问题：
下一步，是代码早就规定好了，还是模型根据当前情况决定的？
这也是我现在对Workflow和Agent最简单的理解：
Tool可以是固定的，但Agent不能只是一个固定的Tool调用流程。
Agent真正改变的，不是系统里多了一个大模型。
而是：
一部分流程控制权，开始从预定义程序转移给模型。
二、这个周末，我换了一种方式做
这次实验，我没有先想“系统要开发哪些功能”。
我先画架构。
传统做法是：先开发一套系统，把数据处理、查询、分析、报表、页面都开发好，再开放API，最后让AI去调用这些系统能力。
也就是：先有系统，再给系统加AI。
这次我想反过来试一次：
先设计Agent，再把Agent需要的能力拆成Tool。
整个结构其实很简单：
用户目标
→ Agent理解和判断
→ 选择Tool
→ Tool执行
→ 返回结果
→ Agent继续判断
→ 直到完成任务
文件读取是Tool。数据解析是Tool。数据转换是Tool。分析计算是Tool。页面生成、报告生成，也都可以成为Tool。
每个Tool只负责一件事情，而且尽量保持确定。
Agent负责判断，Tool负责执行。
如果一定要概括这两种思路，我觉得可以这么说：
传统模式：系统为中心，AI调用系统。
Agent-centric模式：Agent为中心，系统能力成为工具。
这里并不是说传统系统不要了，也不是说代码不要了。
恰恰相反。
越往下走，我越发现Agent架构有一个非常重要的原则：
不是所有事情都应该交给AI。
大模型擅长的是理解、分析、规划、判断这些带有不确定性的工作。
但数据库写入、数学计算、文件转换、权限判断、接口调用，这些事情追求的是准确、稳定、可重复，应该尽量交给确定性的程序。
所以Agent架构真正难的，不是Prompt怎么写。
而是：
什么应该由AI判断，什么必须由程序确定执行。
ReAct经典方法的核心表述是：
“generate both reasoning traces and task-specific actions in an interleaved manner”
也就是让模型的推理和行动交替发生：行动获得新的外部信息，再根据结果更新下一步计划。
这和我们这次的思路很接近：
判断 → 行动 → 获得结果 → 再判断。
所以我后来总结了一句话：
该让AI判断的地方全部写死，智能性出不来；该由程序确定执行的地方全部交给AI，系统又会失控。
架构的核心价值，就是把这条线画对。
三、十年没写代码，为什么还能把Demo做出来
架构大体想清楚以后，我才真正开始动手。
然后一个很现实的问题来了：我已经差不多十年没有认真写代码了。Dify也是第一次用，甚至操作手册、说明文档我都没看，怎么办？
我想让AI帮助我来写AI。我是架构师，AI就是我的数字程序员。
第一步：我把总体思路整理明白，把架构图先画出来。
第二步：我开始逐步展开细节，并询问AI技术路线是否能够支持。
第三步：我第一次操作Dify，让AI来作我的员工。
这件事最让我有感触的，并不是“AI会写代码”。AI会写代码，现在已经不是什么新闻了。
真正重要的是：
架构想清楚以后，我知道应该问AI什么。
我可以不会操作Dify，但我必须知道：数据应该从哪里来；为什么不能写死；Agent和Tool怎么分工；数据和页面为什么要解耦；哪些能力现在可以先不做；哪些边界必须为未来留下。
AI可以给我很多实现方案。
但最终总要有人判断：
这个方案到底是不是对的。
所以AI正在改变一个过去很熟悉的软件工程路径。
过去：先掌握技术，再解决问题。
现在：先理解问题，再借助AI获得实现技术。
不会某种语言，可以问。第一次使用某个平台，可以问。接口报错，可以问。部署不会，也可以问。
很多过去需要长期记忆和练习的“术”，正在变成一种可以随时调用的能力。
但有一样东西并没有因此变得便宜：
判断应该怎么做。
AI降低的是“怎么做”的门槛。
它没有降低“应该怎么做”的门槛。
四、AI时代真正发挥价值的，是架构
做到这里，我越来越觉得，AI时代真正重要的还是架构。
但这里说的架构，不只是画架构图，也不是知道多少框架和方法论。
我想提出一个新词：架构判断力
我觉得这个词更能描述AI时代真正需要的一种能力。
什么叫架构判断力？
我把它定义为：
面对复杂问题，判断真正的问题、设计正确的结构，并识别正确方案的能力。
具体来说，就是三个判断。
1. 判断真正的问题
用户说“我要增加一个功能”，不代表真正的问题就是缺一个功能。
可能是流程不合理；可能是数据没有打通；可能是系统职责划分错了；
甚至可能这个需求根本不应该通过增加系统功能解决。
需求告诉你想要什么，架构要判断真正缺什么。
2. 判断正确的结构
哪些能力应该放在一起？哪些必须拆开？数据应该由谁拥有？谁负责判断，谁负责执行？
什么交给Agent？什么必须做成确定性的Tool？今天哪些东西允许变化，哪些边界必须保持稳定？
这才是架构真正有技术含量的地方。
3. 判断AI做得对不对
AI可以快速写代码，也可以快速给出一套架构。
但：
能运行，不等于设计正确。
Demo能跑起来，也不代表系统能够长期演进。
AI最大的特点之一，就是执行速度非常快。
这既是优势，也是风险。
一个正确的架构，它可以快速实现。
一个错误的架构，它同样可以快速实现。
过去一个错误设计，可能几个月以后才暴露问题。
现在几个小时就可能做出一个看起来很完整的Demo。
所以：
AI提高了实现速度，也放大了架构决策的后果。
这也是为什么，我觉得AI越会写代码，架构越重要。
过去软件工程很难的一件事，是：
怎么把一个正确的设计实现出来。
以后越来越难的可能是：
当实现已经越来越便宜的时候，先做出一个正确的设计。
这就是我理解的“道”和“术”。
语言、框架、数据库、开发平台、Agent平台，这些都是术。
它们当然重要，但都会变化。
真正长期有效的，是：
抽象、边界、分层、解耦、约束。
技术会过时，工具会过时。
但对复杂系统的正确抽象不会过时。
十年前，我要求程序员：专业，会干。
今天这个要求依然成立。
只是“会干”的定义正在发生变化。
未来真正有价值的人，不一定需要亲手写完所有代码，但一定要能够：
把问题看懂，把架构设计对，并且知道AI做得对不对。
这就是我所说的：
架构判断力。
实现越便捷，架构判断越重要。
当AI让“怎么做”越来越便捷，“为什么这样做”和“应该做成什么样”，就会越来越有价值。
企业架构系列文章：
SAP企业架构的分层解析：业务与IT的协同之道，附《SAP企业架构方法指南》下载地址
Togaf10：基于各企业不同的架构风格使用TOGAF框架——每个企业都应该有自己的元模型
IBM解决方案架构在Greenfield（绿地）中的最佳实践方法论
谁是利益相关者？——Togaf10中的5大类22小类利益相关者
业务流程架构梳理优化（基于“房式”流程模型和“Y式”流程模型）
Togaf10：什么是业务场景，如何创建业务场景，附官方案例
详解Togaf-ADM架构开发方法，附Togaf10官方迭代架构开发甘特图
常见的架构治理失败模式和Togaf10推荐的架构治理决策树检查表
自下而上的企业架构EA设计存在什么问题？如何防范？（翻译并解说）
企业架构EA的组织架构模型（Togaf10推荐的企业架构EA能力组织模型）
什么是企业架构？企业架构有什么具体作用？实施企业架构的条件是什么？
什么是企业架构（Enterprise Architecture）
