如何给公司做AI赋能--架构选型篇--谈谈“没有技术信仰”的价值
目录
选型讨论为什么容易变味
聊到 AI 基建选型，大家往往容易陷入焦虑。生态演进太快，难免担心“押错宝”。于是，讨论常常变成非黑即白的站队（“某某家就是强”），或者干脆无限期观望（“再等等，下个月又有新框架”）。但从工程落地的角度来看，这两种心态都解决不了实际问题。
我们团队最终将 DE 平台构建在 Claude Code 上。写这篇文章，并不是为了安利某个具体的工具，而是想聊聊做这个决定背后的推演过程。在技术选型中，推演的思路往往比结论更有普适性，哪怕你最终选择了完全不同的技术栈。
我们真正在选什么
在讨论前，我们需要理清两个常被混淆的概念：模型（Model）决定了系统的智力上限，而执行框架（Harness）——包含会话管理、工具调用、权限控制和上下文组织——决定了这些智力能否安全、稳定、可复现地落地到企业环境中。对于实际的业务赋能项目来说，选型的核心分量其实在于选 Harness。
根据我们前一篇提到的“信任架构”，我们对 Harness 的诉求非常具体：
-
必须能在工具调用前进行机制性拦截（我们系统的 6 个安全 Hook 强依赖于此）；
-
权限规则应当是声明式配置，能被构建系统解析和校验，而不是硬编码散落在代码各处；
-
能力可以模块化封装，并支持按版本装配（支撑我们的 Skill 供应链）；
-
会话能够程序化驱动，并输出结构化的数据流（用于评估回放和聊天桥接）；
-
具备标准的外部工具协议（如 MCP），对接内部已有系统时不至于重复造轮子。
Claude Code 恰好满足了这些条件，这也是我们当初选择它的原因。但我想强调的是，这份需求清单上并没有绑定任何具体的厂商。它本质上是我们自身业务约束的具象化。 内部约束永远比外部厂商的路线图稳定得多。先明确自身的刚需，再去市场上找合适的工具，这种做法能让你的系统在面对生态变化时从容不少。
选型的成熟度体现在退出成本上
引入任何框架都意味着耦合，装作不存在是没有意义的。成熟的工程实践不在于追求“零耦合”，而在于清楚地知道耦合在哪，并为每一个耦合点划定边界。
后来我们在给系统做盘点时，确认整个平台对 Harness 的直接依赖收敛在了四个点：
-
转录格式：评估框架在判定“技能触发”时，依赖解析 Claude 的 stream-json 数据流；
-
技能语义：“由模型自主决定加载哪个技能”是 Claude Code 的特定行为模式；
-
Hook API：拦截时机、标准输入（stdin）协议以及退出码的定义；
-
权限 Schema：特定 settings 文件的语法结构。
除了这四个点，系统的其他部分——包括声明式实例、构建器、技能注册表、评估门禁逻辑、治理控制台等——几乎都是厂商无关的。这并非巧合，而是得益于我们前期的两个架构决策：
-
编译式运行时。我们将实例定义为声明，而 Harness 工作区只是构建产物。未来如果要换框架，本质上是换一个构建目标，而无需重写整个平台。
-
评估断言只看副作用，不探究内部状态。门禁检查的是“执行了什么命令、输出了什么结果”，而不是去窥探 Harness 的内部逻辑。对于唯一有耦合的转录解析，只需在 Harness 之上加一层很薄的适配器即可解决。
在团队内部评审时，我们通常会问一个很接地气的问题：“如果两年后必须迁移，我们需要改哪几个文件？” 如果答不上来，说明耦合处于失控状态；但如果回答“一行都不用改，因为我们做了完美的抽象层”，这也需要警惕——过度设计往往是在为虚无缥缈的“通用性”提前买单。
把兼容性做成探针
AI 框架自身也在快速迭代，配置结构和 Hook 行为可能会随版本发生变化（所谓“漂移”）。我们在风险登记簿里将其列为首位，但应对策略绝不是简单粗暴地“锁死版本”（那安全修复怎么办？），而是采取了务实的三件套：
-
让漂移可见：在每次构建时，将当前框架的版本（如
claude --version）明确记录在构建信息文件中； -
建立契约探针（Probe）：编写专门的测试脚本，校验我们强依赖的框架行为（如 Hook 的出入参语义、环境变量传递）。将其集成在日常的
doctor诊断命令中顺手跑一遍； -
把适配做在构建层：遇到升级导致的不兼容时，优先修改构建模板，而不是去改动运行时的 Hook 逻辑，以此保证运行时的稳定。
这是一个典型的 SRE 理念：底层依赖总会发生变化，通过代码去持续监控依赖的“契约”，远比单纯信任它向后兼容的承诺来得实在。
无聊是一种美德
跳出 Harness 来看，我们平台的外围技术栈朴素得近乎“无趣”：Python 统一用 uv 管理，能用标准库就不引第三方包；构建器只依赖 jinja2 和 pyyaml；控制台后端是轻量的 SQLite；CLI 工具直接写 Bash 脚本；前端则是没有复杂构建管线的静态 SPA。
保持这种克制，是因为我们深知：这套代码未来的读者，大部分还没出现。 平台代码会被后来的接手者、安全审计人员或者想要复刻经验的其他团队反复阅读。每引入一个时髦的新技术，都是在增加他人的认知负担。
做 AI 项目本身就已经站在了技术创新的风口浪尖。正因如此，外围的基础设施才更应当保守。我们应该把有限的“复杂度预算”全花在刀刃（Agent 的核心逻辑）上。
作为工程师，技术选型的底层职业素养其实就是一句话：为将来接手系统的同事选，而不是为了丰富自己的简历选。
关于“押错宝”的焦虑，最后聊两句。经常有人问，万一哪天现在的框架被淘汰了，或者公司战略要求统一更换技术栈怎么办？这完全有可能发生。
但在理清了上述的边界之后，这件事对我们的实际影响其实非常明确：无非是重写那四个薄薄的适配层，然后重新跑一遍所有的评估门禁而已。这是一个边界清晰、工作量可估算的常规工程任务，而不是一场推倒重来的灾难。
面对 AI 时代的“选型焦虑”，我想这可能是最踏实的解法：我们无法准确预测生态的走向，但我们可以主动控制系统的退出成本。 当退出成本变得可控时，选型就不再是赌博，而是一项普通的工程决策。而在基础设施建设中，“普通与可控”往往是我们最期待的状态。