老板甩来两百个 AI Agent,我用第一性原理把它拆成了一套架构
一篇写给架构师的思考笔记:当"宏大的 AI Agent 规划"落到你手上,第一步不是拆任务,而是把它拆到不可再分。
一、先说那个让人头皮发麻的场景
假设你是某个垂直行业(智慧楼宇、工业运维、能源管理都行)AI 平台的架构师。某天老板扔给你一份规划:
"我们要做 200 多个 AI Agent,覆盖十几个业务域,每个 Agent 都能自主感知、决策、执行。"
文档很漂亮,每个 Agent 都有名字、有价值、有故事。但你越看越慌:这到底是 200 个系统,还是 1 个系统的 200 种样子?该从哪儿开工?
大多数人的第一反应是"拆任务、排期、分给 20 个人并行开干"。这恰恰是最贵的错误——因为你还没搞清楚你在解的到底是哪一类问题。
于是我做了两件很"慢"但很值的事:用第一性原理把任务剥到底,再用5 个为什么挖它的根目的。
二、第一性原理:剥掉所有类比,只留不可协商的事实
第一性原理的精髓,是扔掉"别人都这么做"的一切参照,只保留那些无论如何都不能违反的事实,再从这些事实重新推。
我把这个任务剥到底,剩下六条"公理"——每一条都不可协商:
| # | 不可协商的事实 | 为什么绕不过 |
|---|---|---|
| F1 | 大模型会幻觉 | 概率模型的本质,再好的提示也消不到零 |
| F2 | 系统会作用于物理世界,部分动作不可逆 | 一个错误动作有真实的钱/安全/法律代价 |
| F3 | 多租户共享,隔离是二元合规 | 泄漏一次就是失败,没有"泄漏一点点" |
| F4 | 大模型推理有边际成本,生意有毛利红线 | 每次调用都花钱,不是所有决策都养得起一个 Agent |
| F5 | 人的工时有限,目标却是上百 Agent × N 个客户 | 不可能独立造 + 独立验证每一个 |
| F6 | 这上百个 Agent 共享巨大结构(都是"感知→决策→[可选]执行") | 它们是同一个东西的变体,不是上百个原创 |
关键动作来了——从这六条事实,架构会被"逼"成什么样?
F1 + F2 → 必须有确定性安全兜底(闸门 + 出错回退) = 安全内核,不是可选功能
F3 → 租户边界贯穿感知/决策/执行 = 隔离是横切公理
F4 → "上不上大模型"是经济决策 = 不是什么都塞 LLM
F5 → 必须复用 + 并行 + 按依赖和风险排序 = 不能逐个硬造
F6 → 平台装共性 + 一张"可变性地图"装差异 = 这是产品线,不是上百个系统
推到这里我愣了一下:这套架构根本不是我"设计"出来的,是这六条事实的唯一解。 换任何一个尊重这六条的架构师,都会走到同一处。
这就是第一性原理最爽的地方:它把"我觉得应该这样"变成"它只能这样"。
三、这类问题有个学名:软件产品线工程(SPLE)
当我推出"平台 + 可变性地图 + 配置派生"时,其实撞上了一门六十年的老学科——Software Product Line Engineering(软件产品线工程)。
它的核心思想,用一个类比就懂:
大众不为每款车重新设计,而是造一个 MQB 平台,高尔夫、途观、奥迪 A3 都是同一平台配不同参数派生出来的。
你那上百个 Agent = 同一个"Agent 平台"派生的上百款"车"。
SPLE 把工作劈成两条互不干扰的线:
- 领域工程(为复用而造):建平台 + 建可变性模型。一次性投入。
- 应用工程(用复用来造):一个产品 = 在可变性模型上做一次"选择 + 填值"。可大规模并行。
而"可变性模型",就是把哪里能变、能变成什么、有什么约束显式画出来的地图。比如把上百个 Agent 归纳成几个原型(监测型、诊断型、优化型、编排型……),每个原型配一张这样的表:
archetype: 优化型
变化点:
触发模式: [周期, 阈值, 事件]
输入: 来自标准语义标签
动作空间: [设备, 参数, 量纲] # 可变
安全约束: # 强制,不可省
上下限: 必填
权限级: [自动, 需审批, 禁止]
回滚阈: 必填
约束:
- 权限=自动 且 场景=高风险 → 非法组合,拒绝 # 防止配出危险 Agent
看懂这张表,你就抓住了精髓:三个"优化型"Agent 不是三段代码,是同一张模板填三次不同的值。而那段 约束,保证没人能配出"全自动却没有回退"这种要命的组合——这是可变性模型比"复制模板"值钱的地方。
四、5 个为什么:这件事的根目的到底是什么
第一性解决了"架构长什么样",但还有个问题:架构师做这件事,根本目的是什么? 我用 5 Whys 往下挖:
老板给了上百个 Agent,为什么我要先"梳理结构",不直接开工?
- 为什么不直接开工?→ 漂亮的规划不是工程视图,直接铺会重复造、埋雷、返工。
- 为什么会重复造、埋雷?→ 它们同构又互相依赖,却没人把"共性"和"差异"分开。
- 为什么不分开就会乱?→ 每个人各写各的,规模一大,"复制粘贴改一改"就复辟了,平台名存实亡。
- 为什么"各写各的"是根问题?→ 因为没有统一契约约束大家,并行就等于批量制造不一致。
- 为什么"契约"是最底层的答案?→ 因为架构的本质,就是用契约把"不变的"钉死,让"可变的"安全并行——契约缺失就是架构缺失。
挖到底了:
架构师做这件事的根本目的,不是"整理文档",而是"建立让上百份可变工作能安全并行的契约与边界"。 文档、原型、排期都是手段;契约与边界才是目的。
五、于是架构师的做法,也是被"逼"出来的顺序
第一性(约束 + 结构)和 5 Whys(契约 + 并行)在同一处会师,逼出一个不能重排的工作顺序:
| 步 | 做什么 | 被哪条逼出来 |
|---|---|---|
| ① 先钉不变量 | 安全兜底、租户隔离、不可逆动作边界 | F1–F3 |
| ② 再提炼复用结构 | 少数几个原型 + 平台底座 | F6 |
| ③ 把①②编码成契约 | 可变性模型 + 安全闸门契约 + 数据契约 | 5-Why 根因 |
| ④ 用契约解锁并行,按 依赖×风险×价值 排序 | 分批建设 | F5 |
| ⑤ 先用一道"竖缝"验证契约,再从中萃取平台 | 单场景端到端 PoC | F4+F5 |
为什么顺序不能改?不变量必须最先(错了全崩);契约必须在并行前(否则批量制造不一致);平台必须靠竖缝萃取(否则空造一堆没人用的能力)。
最后一条尤其反直觉:别一上来就把平台全造完(SPLE 里叫"主动式",风险最高)。正确姿势是提取式——先用一个真实场景端到端跑通,再从里面把平台和契约"萃取"出来。让真实需求拉动平台,而不是让平台空转等需求。
六、别忘了另一半:时间、规模、组织
上面解的是空间维度(此刻怎么摆)。但同样那六条公理,投影到时间、规模、组织轴上,还会逼出几个最容易被忽略的维度——它们不是新清单,是同一组公理的另一面:
- 可变性建模(F6 沿规模):只有"原型"不够,不显式建模可变性,量产时又会退回各写各的。
- 组织 / 康威定律(F5 沿组织):架构最终会长成你的组织形状。不显式切"平台团队 vs 领域团队",契约就没人守。
- 契约演进(F5+F6 沿时间):契约被几十个 Agent 依赖后,"改契约"会炸全场——第一天就要带版本和兼容策略。
- 爆炸半径(F2 沿依赖):单个 Agent 的安全闸门,管不到"平台枢纽挂了牵连几十个 Agent"。
- 规模化评测(F1 沿规模):幻觉要求持续验证;改一次模板,得知道没弄坏下游几十个。
- 单位经济(F4):低价值高频的决策,压根不该进 Agent 路径。
守住那六条公理,这些维度会自己浮现;忽略它们,等于只解了空间,丢了时间与规模。
七、三句话带走
- 面对"上百个 AI Agent"的宏大规划,先别拆任务——先用第一性原理拆到不可再分。 你会发现它是一个"软件产品线"问题,不是"上百个系统"问题。
- 架构师的根本产出不是文档,是契约与边界。 契约把不变的钉死,让可变的安全并行——这就是架构的定义。
- 别主动式造平台,用一道竖缝把它萃取出来。 让真实场景拉动平台,是唯一不空转的路径。
第一性原理最大的价值,不是让你显得聪明,而是把"我觉得应该这样"变成"它只能这样"——当你能向团队和老板证明这是唯一解时,推动力完全不一样。
这套方法不限于 AI Agent。任何"要造很多个相似的东西"的场景——微服务、插件生态、多租户配置——第一性原理 + 产品线思维都成立。