核心问题就是“怎样让一个不确定性的 LLM 或者说大模型，安全地操作一个确定性的企业业务系统？”

Agent 在与企业业务系统交互的过程中是切切实实的会产生副作用，并且是对业务系统或者业务流程有影响的副作用，可能牵一发而动全身，直接调 api 的话，一旦 Agent 参数拼错、状态过期，最后产生了业务系统中的错误操作，那就是生产事故

所以不能只是简单的让 Agent 直接调 api，而是需要把中间过程拆成几个边界明确的层

用户自然语言
    ↓
LLM / Agent
    │  负责：理解意图、选择能力、生成参数
    ↓
技能声明
    │  声明：这个能力是什么、何时调用、需要什么参数、风险和权限
    ↓
cli
    │  负责：确定性的参数组装、命令执行、HTTP 路由
    ↓
Scenario
    │
    ├── Preview
    ├── Frozen Payload
    │
    ↓
人工 Confirm
    │
    ↓
Reentry Validate
    │
    ↓
Replay
    │
    ↓
原有业务 Service
    ↓
数据库 / HR / ERP / OA 等业务系统

简单来说就是 LLM 负责决策，确定性程序负责执行，服务端负责最终安全边界

那我们是不是可以将其分成三个模块

❓为什么要多一层 CLI?
A：CLI 实际承担的是 Agent 与业务接口之间的确定性适配层。Agent 只负责选工具和生成结构化参数，而 CLI 负责把参数规范化成稳定的命令和请求协议，这样的话就可以把 Agent 的不确定性限制在 Tool Calling 之前（尽量把模型的不确定性限制在“工具选择和参数生成”这一层，Tool Call 之后通过参数校验、实体消歧、权限控制和确定性执行链路，把后续行为收敛成可验证的程序逻辑），而且在后端接口有变动的时候或者多个 Agent 接入时，也不需要把业务细节都暴露给模型

主要链路#

Preview → Frozen Payload → Confirm → Reentry → Replay

Preview#

举个例子
用户说“把张三的财务权限收回来”
而模型根据意图找到对应 Skill，然后根据姓名“张三”调用工具
问题来了，如果公司可能有多个张三，这个时候不可能让模型直接猜是谁，而是会列出候选列表，并且算出“如果执行，会发生什么”，