为什么「框架」停在了演示环节
用 Python 写一个智能体原型在 2026 年已经是半小时的事：声明一个模型、挂上几个工具、写一段指令。真正让团队卡住的是之后的事——把它部署到生产环境。API 层、会话持久化、密钥管理、观测告警、多智能体目录的管理界面，这些「容易的 10% 之外」的部分，LangGraph 和 CrewAI 这类库一概不管。
ApowerB 是一个 Apache 2.0 许可的开源智能体框架，它的自我定位不是「又一个编排库」，而是一个完整的运行时服务：FastAPI 后端、Typer CLI、REST API、配套前端 apowerb-ui，加上 Docker Compose / Helm / Kubernetes 部署清单。用官方文档的话说，它提供的是「构建、编排和运营生产级 AI 智能体」的全栈环境。第三方评测文章把这个定位概括为一个尖锐的判断：框架.stop 在演示环节，而 ApowerB 想解决的是从原型到生产的「其余 90%」。
ApowerB 的架构选择可以浓缩成一句话：Agent 不是代码，是数据。定义（指令、模型、工具、子智能体、守卫规则）全部存放在 PostgreSQL 中，运行时读取这些行并动态生成可执行模块。这一选择把「修改一个智能体」从软件发布流程降格为一次数据库更新——同时引入了一类新的工程问题：派生状态漂移。
核心机制：Agent 是数据库里的一行
理解 ApowerB 的关键，是看它如何处理「智能体定义」这个概念。传统路径下，一个智能体就是一个 Python 文件：声明模型、附加工具、携带指令，提交进仓库、随应用部署。这条路径在非工程师需要改一段 Prompt、或者你同时运营着四十个智能体服务十二个团队、每一次措辞修改都变成一次发布的时候，开始失灵。
ApowerB 的做法是：在界面上创建一个智能体（名称、类别、模型提供商），写入的是一条数据库记录；运行时在启动阶段把这些记录物化为 Python 模块。第三方作者 worldprogramming 实测了这条链路：创建名为 article_demo 的智能体后，Postgres 里出现一行记录（agent_id、agent_name、agent_type、agent_model 等字段，模型是 anthropic/claude-sonnet-4-5 这样的字符串），同时磁盘上出现一个约七行的桩模块——其中真正干活的只有两行：
# agents_pool/agent1/agent.py — 运行时生成的桩模块
from apowerb.core.agent_helpers import to_agent
root_agent = to_agent(agent_name = 'agent1')这个桩模块只是一个「钩子」：ADK 能导入它，而智能体的全部实质内容——指令、模型、工具、子智能体、守卫、输出模式——由 to_agent() 在加载时从数据库读取。智能体的编辑面因此从「代码仓库」变成了「API 和界面」：定义可以没有凭据而存在（表单允许 API 密钥留空），只是在配置密钥之前无法应答。
执行层由 Google ADK（Agent Development Kit）承担，模型接入则交给 LiteLLM 统一路由：Anthropic、OpenAI、Mistral、Gemini、OVHcloud、Groq 以及本地 Ollama/vLLM 都走同一套配置。官方 README 列出的编排模式覆盖 base、parallel、sequential、loop 四种，支持层级化子智能体组合，工具系统包含 31 个工具模块（Google Workspace、Microsoft 365、数据库、RAG 等）。
| 分层 | 组件 | 职责 | 技术选型 |
|---|---|---|---|
| 定义层 | PostgreSQL 数据行 | 智能体指令、模型、工具、技能、MCP 服务器配置 | PostgreSQL（自动迁移） |
| 物化层 | agents_pool 桩模块 + to_agent() | 启动时把数据行转成可导入的 Python 模块 | adk_agent_builder.py |
| 执行层 | Google ADK | 智能体运行、编排（base/parallel/sequential/loop）、子智能体 | Google Agent Development Kit |
| 模型层 | LiteLLM 路由 | 多提供商统一接入，智能体与厂商解耦 | LiteLLM |
| 服务层 | FastAPI + Typer CLI | REST API、CLI 管理、SSE 流式输出、Webhook | Python 3.12/3.13 + FastAPI |
| 运营层 | 管理面板 | 用户、组、权限、MFA 强制、会话审计与吊销 | 开源核心内置 |
启动自修复：派生状态漂移的工程解法
「数据库即真源」立刻带来一个问题：磁盘上的 agents_pool 目录和数据库可能不一致。worldprogramming 的拆解文章列出了三种典型故障：恢复卷快照时丢了数据库、环境间同步时丢了目录、包重命名后留下一个导入不存在模块的残桩。三者在运行时的表现完全相同——用户一开口，ModuleNotFoundError。
ApowerB 的解法是启动阶段的对账而非信任。ensure_agent_modules() 函数在每次启动时为每个智能体重建「缺失或过期」的 agent.py。这里最有意思的设计是对「过期（stale）」的判定：一个存在但已损坏的文件比缺失更危险，因为朴素的 os.path.exists 检查会认为它健康。修复逻辑因此会读取桩内容、校验其携带的导入行是否仍然有效，失效则重新生成。
这条设计对我们有一个超出 ApowerB 本身的启示：当你把「状态」从代码里搬出去（无论搬进数据库还是配置中心），你就签下了一份对账契约——系统必须能在下一个启动周期里自愈，而不是等人工去逐个修复。第三方评测（ClawdBytes）把这一点称为「严格的保鲜检查」要求：内存缓存或文件副本不得偏离数据库真源。这是数据库优先路线的固定税，ApowerB 只是把它显式写进了启动序列。
能力栈：LiteLLM 路由、RAG 与 Text-to-SQL
RAG 作为运行时能力而非 SaaS 依赖
很多框架把检索外包给闭源 API，ApowerB 则自带一条模块化 RAG 管线（独立的 th2rag FastAPI 服务）：
文档 → Docling 转换/OCR → HybridChunker 结构感知分块
→ gtr-t5-large 嵌入 → LanceDB 向量库 → 检索 → 生成每个环节都藏在基类后面（BaseEmbedding、BaseGenerator 等），换嵌入模型或生成模型是子类化，而不是动手术。知识库按智能体关联而非全局单库，支持本地文件、URL、数据库查询结果和 S3 对象入索引。对于在意数据边界的企业，这条「开源组件拼装、可整体自托管」的 RAG 路线是一个值得注意的参照系——它与直接调用闭源检索 API 的方案构成两种成本与控制力的取舍。
原生 Text-to-SQL
智能体可连接 PostgreSQL 或 MySQL，在智能体回合内完成模式内省、自然语言到 SQL 的生成、执行与结果返回。值得强调的不是「大模型会写 SQL」，而是连接、内省、生成、执行全部发生在运行时内部——Text-to-SQL 从一个脆弱的外部集成变成了平台能力。第三方评测同时指出其代价：宽表模式下模式上下文会显著消耗 token，需要精细管理以避免成本失控。
模型接入与解耦
执行层与模型接入刻意分离：工具与编排逻辑不需要知道最终是哪家提供商执行了模型调用。这对两类团队特别有用——想在不同模型之间做基准对比的团队，以及要求供应商可替换性的企业。这与本站此前解构的 Strands Harness「开箱默认值」思路形成对照：Strands 在 SDK 之上固化默认工程实践，ApowerB 则在框架之上固化了一个完整运营平台。
事件驱动：从请求/响应到 Webhook 与调度
多数智能体演示停留在「HTTP 请求进来、回答出去」的请求/响应模式。ApowerB 支持反方向的工作流：外部事件先触发，智能体再行动。当前实现包括邮件触发的智能体——Gmail 走 Google Cloud Pub/Sub 推送通知，Outlook 走 Microsoft Graph 变更订阅（带 clientState 校验）；订阅续期由后台处理，因为 Gmail 的监听七天后过期、Outlook 三天后过期，运行时会周期性续订。再叠加 cron 式定时运行与 SSE 流式输出（逐 token 输出、RAG 摄取进度、通知），智能体成为事件驱动系统里的一个常驻组件。
这个能力清单解释了为什么把 ApowerB 归入「框架」并不完全准确：它同时是一个带持久会话、可吊销会话、密钥加密（Fernet 32 字节密钥）、OAuth 集成（GitHub、Google、Microsoft、LinkedIn）和缺陷上报工作流（附请求日志与可选截图、经分诊后进 GitHub）的运营平台。会话持久化意味着智能体具备跨重启的对话上下文——这与本站此前讨论的 Pi Durable 长时运行基底解决的是同一类问题，只是切入点从「终端智能体的状态」换成了「平台级智能体目录」。
开源边界：哪些能力被留在了商业版
ApowerB 采用开放核心（open-core）模式，官方 README 对此写得异常坦率：计费、消耗分析、潜客开拓、身份提供商登录、智能体评估、监督界面、组织管理这些能力以独立商业模块（commercial bricks）交付，开源仓库里只有挂载点——那些路由返回 404 意味着「不在本版本」，而非「对象不存在」。管理面板（用户、组、权限、MFA 强制）在开源版内；唯独组织管理单独售卖，理由是「决定一个人属于哪个租户，管束的是其他人的触达范围，而不是安装者自己」。
| 能力 | 开源核心 | 商业版 |
|---|---|---|
| 智能体定义/物化/执行（ADK + LiteLLM） | ✅ | — |
| RAG 管线（Docling + LanceDB）与 Text-to-SQL | ✅ | — |
| Webhook 事件驱动、定时运行、SSE 流式 | ✅ | — |
| 管理面板（用户/组/权限/MFA） | ✅ | — |
| 智能体评估、监督界面 | 仅有挂载点 | ✅ |
| 计费、消耗分析、SSO、组织管理 | 仅有挂载点 | ✅ |
对企业选型者来说，这份边界清单本身就是信息：智能体评估（evaluation）和监督（supervision）这两个在治理语境下越来越关键的环节，恰恰是被划出开源核心的部分。如果你评估 ApowerB，需要同时评估商业模块的价格与这两项能力是否可以用本站此前讨论过的开源评测方案（如 ThinkingBox 这类数据库终态判定框架）自建替代。
路线之争：代码优先 vs 数据库优先
最后把这条路线放进更大的坐标系。代码优先（Agent 即代码）的好处是版本化、可审查、可测试，这是仓库存在的意义；它的成本是每次修改都要走发布。数据库优先（Agent 即数据）把修改降为 UPDATE，代价是放弃了代码路径上的全部工程保障，并新增派生状态对账负担。两条路线没有赢家，只有场景适配：
| 维度 | 代码优先（LangGraph/CrewAI 典型用法） | 数据库优先（ApowerB） |
|---|---|---|
| 修改成本 | 提交 + 审查 + 发布 | UPDATE 或界面操作，即时生效 |
| 版本控制 | Git 天然支持 | 依赖数据库自身的版本能力（官方未披露完整方案） |
| 适合角色 | 工程师主导 | 允许非工程师通过界面修改 |
| 多智能体运营 | 每个智能体都是代码资产 | 目录化管理，规模化的原生形态 |
| 新增风险 | 发布摩擦累积 | 派生状态漂移、缓存一致性问题 |
| 基础设施所有权 | 团队自建 API/持久化/认证层 | 平台内建，但接受运行时强约束 |
需要保持审慎的地方同样明确：ApowerB 目前没有公开的独立基准数据，社区规模与维护节奏在第三方镜像中「无法从公开信息确证」；项目尚处早期版本阶段；安全审计信息未见披露；Text-to-SQL 的宽表 token 成本、数据库行到运行时行为的可追溯性（谁在什么时候改了指令，审计粒度如何）都还是开放问题。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
但作为一个「信号」，ApowerB 的价值是清晰的：当智能体从单个demo走向企业内的规模化运营，定义的存放位置、修改的权限边界、派生状态的一致性，会像当年的数据库迁移与配置中心一样，成为工程团队的必答题。数据库优先路线未必是终局，但它把这道题提前摆上了桌面。