第一部回答的是“如何用通用工具把 AI 跑起来”（实操），第二部回答的是“如何让 AI 在企业里不出错、不乱来、可审计”（原理）。

第一部提到的随机性问题——同样的问题两次回答不一样、该拒绝的不拒绝、该留痕的不留痕——正是通用工具在企业场景下“不敢用”的根源。第二部用规则的确定性约束模型生成的随机性：意图识别、规则引擎、审批链、权限审计、可训练配置，构成“生成 × 裁决”的工程闭环。

第二部面向需要为业务系统构建内嵌智能体能力的架构师与开发者；普通用户可先读第 1~5 章上手，再回到本部分理解“为什么这样做才可靠”。

第 6 章：绪论：规则驱动的智能体

6.1 从大语言模型到业务智能体

大语言模型（LLM）的本质能力是语言建模：给定前文，预测续文。当这一能力被嵌入业务系统时，一个朴素的做法是直接向模型提问并展示回答。然而业务系统对输出的要求远不止"通顺"：

• 正确性：下单数量不能超库存，售价不能低于成本线；

• 可审计：每笔操作需要留下谁、何时、做了什么；

• 权限：不同角色可见与可操作的范围不同；

• 安全：模型不能泄露敏感信息，也不能被提示注入操控。

「智能体」这一概念正是在此背景下被引入：将 LLM 封装为一个具备感知、决策、行动能力的组件，使其能在约束条件下完成业务任务。而约束从何而来，正是 Agent 框架设计的核心分水岭——也是本书全部章节的总纲。

6.2 工程问题的本质：业务正确性的来源

当一个 LLM 应用从对话原型演进为生产系统，工程问题会集中爆发。但这些问题并非彼此独立，它们有一个共同的根源：系统的可信输出依赖一条不稳定的链路——模型输出 → 直接呈现 → 直接落库。链路中的每一环都可能被模型幻觉、越权操作、注入攻击或过期数据破坏。

应对这些挑战的常见路径有三条：其一，依赖通用编排框架，以图结构组织智能体，规则的约束力取决于提示词措辞；其二，引入独立的安全与合规组件栈，自行拼装；其三，构建内嵌的、以规则为第一约束的运行时——本书所研究的路线。

核心原理： 业务正确性不应是"模型碰巧答对"，而应是"系统结构上不可能答错"。后者的工程含义是：将关键裁决从概率性的模型推理中剥离出来，交给确定性的规则与审核机制。模型负责"听懂与表达"，规则负责"裁决与约束"。

6.3 设计定位与四条约束

绳墨 Runtime 的核心设计定位可以概括为一句话：业务正确性靠规则引擎 + 审核链，而非 LLM 编排。这一原则展开为四条设计约束：

1. 硬规则不可绕过：规则引擎中 bypass=false 的规则，返回 block 时不可被任何角色覆盖，包括管理员；LLM 输出同样不可覆盖。
2. 审核链不可跳过：每笔关键操作须经过七层审核方可落库，链式哈希保证记录不可篡改。
3. 配置可训练但须审批：规则参数、槽位定义、子意图关键词、审批链均可通过训练修改，但修改须经审批链；审批链本身亦可训练（治理之治理）。
4. 单智能体为主：每轮路由仅一个智能体处理，降低编排复杂度与调试成本。

这四条约束回答了四个本质问题：谁能覆盖裁决（没人）、操作能否无痕（不能）、配置能否失控改动（不能）、编排能否无限复杂（不必）。

6.4 框架全景与模块地图

flowchart TD
    BIZ["业务层（框架边界之外）
领域 Agent · 业务规则 · HTTP API · MCP · 数据库迁移 · 部署配置"]
    subgraph RT["runtime/ 框架运行时（本书叙述范围）"]
        direction TB
        subgraph SEM["语义层"]
            direction LR
            S1["intent_recognition 意图识别"]
            S2["sub_intent_engine 子意图"]
            S3["slot_engine 槽位提取"]
            S4["query_param_parser 附加词"]
        end
        subgraph ORC["编排层"]
            direction LR
            O1["coordinator 路由调度"]
            O2["base_agent 生命周期"]
            O3["multi_hop 多跳拆解"]
            O4["workflow_enforcer 流程约束"]
            O5["chain_gate 链式 Gate"]
            O6["approval_chain 审批链"]
        end
        subgraph GOV["治理层"]
            direction LR
            G1["rule_registry / rule_engine 规则引擎"]
            G2["audit_engine 审核链"]
            G3["permission RBAC+ABAC"]
            G4["sod 职责分离"]
            G5["agent_security 安全防护"]
            G6["module_toggles 模块开关"]
        end
        subgraph INF["基础设施层"]
            direction LR
            I1["trace 链路追踪"]
            I2["session_manager 会话"]
            I3["logger 日志"]
            I4["cache 缓存"]
            I5["event_bus 事件总线"]
            I6["file_storage 存储"]
            I7["streaming SSE"]
            I8["scheduler 调度"]
            I9["auth 认证"]
        end
    end
    BIZ --> RT

框架在结构上划分为四个层次：语义层负责"听懂"，编排层负责"怎么走"，治理层负责"能不能做"，基础设施层提供"运行的底座"。分层本身就是原理——每一层只承诺一类职责，任何一条执行路径都必须穿过治理层，这正是"业务正确性在结构上不可能被绕过"的实现方式。

6.5 技术选型：零第三方依赖的工程意义

框架核心仅依赖 Python 标准库。这一约束是设计决策而非偶然：

1. 无框架升级风险：不依赖外部编排生态，版本演进完全自主可控；
2. 内网可部署：企业内网常禁止外网拉取依赖包，标准库零安装即可运行；
3. 降级语义清晰：redis、boto3 等可选依赖未安装时自动降级为内存或本地实现，框架仍可独立运行。

原理： 依赖即风险。每引入一个第三方能力，就引入一个不可控的失效点、升级点与供应链审计面。零依赖不是炫技，而是把"运行时可失效的东西"压到最少。

6.5.1 与通用编排框架的定位差异

技术选型需要明确边界。通用编排框架（如以图结构组织智能体的 LangGraph 系、以多智能体对话为范式的 AutoGen 系）与绳墨 Runtime 的差异是定位性的，而非能力高下：

两类框架各有所适：通用编排框架适合快速搭建原型与探索性应用；以规则为第一约束的运行时适合企业内部、合规要求高、业务规则明确的场景。

6.5.2 规则优先的论证框架与适用边界

"业务正确性靠规则"需要一个可检验的论证框架，而非信念。论证基于两类错误的成本不对称：

当"假放行的成本"显著高于"假阻断的成本"时，规则优先（且失败默认阻断）是理性选择——这正是制造业订单、质检、库存流转场景的特征。反之，在创意生成、探索性任务中，假阻断的代价（扼杀创新表达）可能高于假放行，此时规则优先不适用。

适用边界（反向界定）： 本框架的设计目标场景满足三个条件——① 业务事实可结构化（订单、库存、状态有确定 schema）；② 决策可被规则描述（存在明确的成本线、审批链、状态机）；③ 错误不可逆性高（落库即事实）。不满足条件的场景（开放创意、语义无界的自由问答、低风险高探索性任务）应选用模型主导的编排，而非本框架。

6.5.3 质量度量框架（非功能性视图）

专家级工程评审以可度量的视图收尾。本书各章的设计决策可统一映射到四组度量：

6.6 本章小结

• 智能体的业务化必须回答"约束从何而来"——这是全书的第一个原理问题；

• 业务正确性应来自结构约束，而非模型概率；

• 四条设计约束分别回答"谁能覆盖裁决、操作能否无痕、配置能否失控、编排能否无限复杂"；

• 四层架构与零依赖是"正确性在结构上不可绕过"的实现方式。