Skip to main content

系列简介

大型语言模型(LLM)非常擅长“给出建议”。

它们可以:

  • 理解非结构化输入
  • 推断用户意图
  • 生成结构化结果
  • 解释自己的推理过程

这使得 LLM 看起来非常适合接入业务系统。

但必须明确一点:

建议 ≠ 决策
生成 ≠ 执行

本系列从一个核心问题开始:

如何让 LLM 参与真实业务系统,
但不把责任交给模型?


核心问题是什么

大量 AI Agent 示例遵循一种常见模式:

  1. 用户提出请求
  2. 模型推理
  3. 模型给出结论或动作
  4. 系统直接执行

这种模式在演示中很有效, 但在真实业务系统中极其危险。

在会计、财务等高约束领域:

  • 每一次写入都会产生连锁影响
  • 错误会被长期累积
  • 责任不能转移给用户或模型

一个让 LLM 直接做决定 的系统, 并不是自动化,而是失控


参与,但不授予权力

在 BookiAI 中,我们遵循一个基本原则:

LLM 可以参与决策过程,
但默认不拥有执行权。

这意味着角色必须被明确区分:

  • LLM 负责 提出建议
  • 系统负责 做出决定
  • 执行过程必须 受治理与约束

要做到这一点,仅靠 Prompt 是不够的。


从直觉到架构

本系列记录了我们如何将上述原则 逐步落实为可执行的系统设计:

  • 拆分 生成 / 审阅 / 执行 三个角色
  • 用对象化结构表达 AI 的输出,而不是自然语言
  • 在建议进入系统前进行校验与评估
  • 引入代表系统意志的 Controller
  • 人工执行优先 出发,逐步演进到自动化

这些设计并非过度工程, 而是在真实系统中被反复验证后的结果。


为什么选择会计系统作为切入点

会计系统的特点是:

  • 每一笔分录都会影响多个报表
  • 错误往往不会立即暴露
  • 修正必须通过冲销而不是覆盖

如果 LLM Agent 能在这里被治理, 那么它们在其他业务系统中也同样可控。

BookiAI 提供了一个真实而严格的试验场, 而不是假设理想条件成立。


本系列做什么,不做什么

本系列 会做的事

  • 记录真实的系统设计决策
  • 解释为什么这样设计
  • 提供可复用的工程思路

本系列 不会做的事

  • 提供现成框架或 SDK
  • 收集 Prompt 技巧
  • 宣称 AI 可以替代专业角色

这是关于 系统责任 的讨论, 而不是关于模型能力的炫耀。


接下来

下一篇将从最关键的限制开始:

👉 为什么不能让 LLM 直接写账

理解这一点, 是后续所有 Agent 设计的前提。


本文由 ChatGPT 撰写,经 BookiAI 团队审阅。