在当前 AI 技术飞速发展的浪潮中，大模型（LLM）已从通用问答场景逐步向企业级业务场景渗透。然而，企业办公场景与通用场景存在显著差异 —— 业务中充斥着 “黑话”“特有流程” 和 “私密数据”，这使得传统问答型 AI 助手难以真正融入业务系统。特别是在业务数据处理、多系统协同操作等核心环节，通用 AI 往往 “水土不服”。
本文将以销售运营系统排产场景为例，详细拆解如何通过工程化手段构建 AI Agent，解决企业级场景下的 “理解难”“执行长”“交互差” 问题，最终打造业务人员可自主使用的 “工作小助手”，实现业务增效与自主可控的双重目标。
一、企业级 AI Agent 的核心痛点：为何通用方案不适用？
在企业办公场景中，AI Agent 面临三大核心挑战，这也是通用 Coding 类 Agent（代码语言通用、逻辑标准化）无需解决的问题：
-
业务语言理解难：如销售排产中的 “拼柜数据”“未排产订单”“整柜排产” 等术语，LLM 无预设认知，易出现理解偏差；
-
业务流程执行长：单个任务常跨多系统（如从销售系统拉取订单→拼柜系统核对数据→排产系统写入计划），单次对话易因上下文过载出错；
-
业务自主可控性低：企业数据敏感（如订单金额、交付日期），需确保 AI 执行可中断、可验证、可追溯，避免 “黑箱操作”。
为验证 AI 与企业业务系统的融合方案，我们选择销售运营排产场景作为切入点：销售运营人员需定期拉取 “未排产订单”，结合 “剩余未排产数量”“订单交付日期”“拼柜系统整柜数据”，最终指定排产日期。下文将通过三个版本的 AI 助手设计，逐步解决上述痛点。
二、AI 助手的三版工程化演进：从 “能用” 到 “好用”
2.1 第一版：纯提示词 + 工具调用（验证可行性）
设计思路
第一版的核心目标是 “验证 LLM 能否理解业务逻辑并调用工具”，采用 “全量提示词 + 知识库 + 工具调用” 的极简架构：通过一次性输入详细规则（含角色、流程、输出规范），让 AI 自主完成 “问题分析→任务拆解→执行→输出” 全流程，且所有写入操作需用户确认后执行（保障可控性）。
核心提示词框架
你是一位「智能业务分析-排产助手」，具备以下能力：
1. 问题分析：识别用户意图，判断是否信息完整，主动追问澄清。
2. 任务拆解：将复杂需求拆成可执行子任务，标注依赖与输入输出。
3. 任务执行：可调用工具获取外部数据/解释专业术语；任何「写系统」操作只输出 ```action 代码块，不真执行。
4. 上下文记忆：结合历史对话判断方向是否偏离，主动纠偏；支持多轮追问与增量更新。
5. 输出规范：
① 拟写入数据 → 先输出 Markdown 预览表（关键字段即可）；
② 用户确认后 → 再输出 ```action 代码块（语言标记=action，含接口调用参数）；
③ 预览表下方提示"请确认；回复『确认』即输出可执行报文，回复『修改』请指出调整点"。
--- 输出流程（必须严格遵守） ---
Step 1 问题分析→用户意图/完整性/需调用工具；
Step 2 任务拆解→子任务清单（含依赖）；
Step 3 任务执行→先预览表，再等用户确认后输出action；
Step 4 验证与纠偏→判断是否符合原意，提示下一步。
方案痛点
-
灵活性差：提示词需预设所有业务细节（如 “拼柜数据字段”“排产规则”），换一个业务场景需重新编写提示词；
-
容错率低：单次对话需完成 “拉数据→算排产→写系统” 全流程，数据量大或流程复杂时易遗漏步骤（如忘记核对拼柜数据）；
-
交互僵硬：执行过程不可中断，用户需等待全流程结束才能看到结果，中间出错需重新开始。
2.2 第二版：提示词链 + 状态管理（解决 “执行长” 问题）
设计思路
针对第一版 “不可中断、容错率低” 的问题，第二版引入 “提示词链” 和 “状态管理” 两大工程化手段：
-
提示词链：将全流程拆分为 “单步提示词”，AI 每完成一个子任务，自动生成 “下一个子任务的提示词”，实现循环迭代；
-
状态管理：新增
executionHistory（执行历史）、globalVars（全局变量）、pendingSubTasks（待执行任务）等字段，记录任务进度、错误原因和中间数据，避免重复踩坑。
核心架构优化
-
运行方式：从 “一次性执行” 改为 “单步执行→返回 JSON→外部再次调用”，禁止一次性跑完所有子任务；
-
状态控制：通过
status字段（running/paused/finished/error）控制流程，如信息不足时status=paused，等待用户补充； -
错误避免：每次生成
nextPrompt时，自动摘要最近 3 步执行历史（含错误原因），提醒 AI 避免重复错误。
关键 JSON 输出模板
{
"status": "running",
"currentSubTaskId": "st-20251020-001",
"currentSubTaskDesc": "拉取销售系统未排产订单",
"result": "Markdown表格（订单ID/未排产数量/交付日期）",
"nextPrompt": "【历史执行摘要】- st-20251020-001：成功拉取10条未排产订单...请调用拼柜系统，核对每条订单的整柜数据",
"contextSnapshot": {
"originalDemand": "用户原始排产需求",
"completedSubTasks": ["st-20251020-001"],
"pendingSubTasks": ["st-20251020-002（核对拼柜数据）"],
"globalVars": {"未排产订单列表": [...], "当前日期": "2025-10-20"},
"executionHistory": [
{
"step": 1,
"subTaskId": "st-20251020-001",
"status": "success",
"resultDigest": "拉取10条未排产订单，交付日期集中在11月",
"userFeedback": "无",
"reviseStrategy": "无"
}
]
}
}
方案优势与残留痛点
-
优势：支持任务中断（
status=paused）、错误追溯（executionHistory）、多系统扩展（新增工具只需补充子任务），业务人员可通过自然语言控制多系统协同； -
痛点：用户需等待 “单个子任务执行完成” 才能看到结果，若子任务涉及复杂计算（如 1000 条订单的拼柜核对），等待时间仍较长，交互体验不佳。
2.3 第三版：MD SSE + 提示词链（优化 “交互差” 问题）
设计思路
第三版的核心目标是 “提升用户实时交互体验”，引入MD SSE（Server-Sent Events）实时输出和action 暂停机制：
-
实时输出：AI 执行过程中，通过 SSE 实时返回 Markdown 格式的中间结果（如 “正在拉取订单数据→已拉取 50%→已完成”），用户无需等待；
-
action 暂停：仅当涉及 “写系统 / 调接口” 等关键操作时，AI 暂停并提示用户确认，其他内部计算（如数据核对、规则判断）由 AI 自动完成，兼顾效率与可控性。
核心优化点
-
输出顺序优化：先返回 “对人友好的正文”（中间结果、预览表），再返回 “机器可读的 agent-json”（状态、nextPrompt），用户先看结果，系统再续跑；
-
工具调用策略：区分 “内部计算” 和 “外部 action”—— 内部计算（如数据过滤）AI 自动完成，外部 action（如写排产系统）必须暂停等待用户确认；
-
修正指令协议：支持
continue（继续）、revise-<子任务ID>（回退修正）、restart（重启）等指令，用户可随时干预流程。
关键交互流程示例
-
用户输入需求：“帮我处理 10 月未排产订单，按整柜排产”；
-
AI 实时输出：
-
正文：“正在拉取销售系统 10 月未排产订单… 已拉取 10 条，订单 ID：ORD001~ORD010。下一步将核对拼柜数据（自动执行）…”；
-
agent-json：
status=running，nextPrompt=“已拉取订单，自动调用拼柜系统核对整柜数据”；
- AI 自动核对拼柜数据后：
- 正文：“拼柜数据核对完成，共 3 条订单需按整柜调整。拟排产计划如下（Markdown 预览表）：
| 订单 ID | 排产日期 | 数量 |
|---|---|---|
| ORD001 | 10 月 25 日 | 400PCS |
| ORD002 | 10 月 26 日 | 350PCS |
| … | … | … |
{
"url": "/api/production/schedule",
"method": "POST",
"body": {"orders": [...]}
}
⏸️ 请执行上方 action 并回传结果”；
- agent-json：
status=paused，actionWaiting=true；
-
用户确认执行：回复 “确认”；
-
AI 完成写入：正文 “排产计划已写入系统，执行结果：成功。是否需要生成排产报告？”，agent-json：
status=finished。
方案价值
-
业务增效：业务人员无需懂技术，通过自然语言即可完成 “多系统协同 + 复杂排产”，原本 2 小时的工作缩短至 10 分钟；
-
自主可控：关键操作可暂停确认，执行过程可追溯（
executionHistory），错误可回退修正，符合企业数据安全要求； -
技术复用：IT 人员只需提供 “原子化工具”（如拉订单接口、拼柜查询接口），AI Agent 可基于工具灵活组合业务流，适配不同场景（如后续扩展 “采购订单处理”“库存预警”）。
三、企业级落地的核心工程化经验
-
分层设计原则：将 AI Agent 拆分为 “业务层（提示词链 / 状态管理）”“工具层（原子化接口）”“交互层（SSE 实时输出）”，IT 人员负责工具层，业务人员负责业务层，解耦分工；
-
可控性优先：所有涉及 “数据写入”“接口调用” 的操作，必须经过 “预览→确认→执行” 三步，且执行历史不可篡改，满足企业审计需求；
-
渐进式落地：从单一场景（如排产）入手，验证三版方案后，再扩展到多场景（如财务对账、客户跟进），避免一次性投入过大导致失败。
四、总结与展望
本文通过销售运营排产场景，验证了 AI Agent 在企业级落地的可行性：通过 “提示词链 + 状态管理 + SSE 实时交互” 的工程化手段，解决了 LLM 在企业场景中的 “理解难”“执行长”“交互差” 问题，最终实现 “业务人员用自然语言操作多系统，IT 人员提供原子化工具” 的高效模式。
未来，可进一步探索 “多 Agent 协同”（排产 Agent 与库存 Agent 联动）等方向，让 AI 真正成为企业业务的 “核心助手”，而非简单的问答工具。
附录
V1提示词
你是一位「智能业务分析-排产助手」，具备以下能力：
1. 问题分析：识别用户意图，判断是否信息完整，主动追问澄清。
2. 任务拆解：将复杂需求拆成可执行子任务，标注依赖与输入输出。
3. 任务执行：可调用工具获取外部数据/解释专业术语；任何「写系统」操作只输出 ```action 代码块，不真执行。
4. 上下文记忆：结合历史对话判断方向是否偏离，主动纠偏；支持多轮追问与增量更新。
5. 输出规范：
① 拟写入数据 → 先输出 Markdown 预览表（关键字段即可）；
② 用户确认后 → 再输出 ```action 代码块（语言标记=action）；
③ 前端会把该代码块渲染成「执行按钮」，用户一键调用接口。
6. 安全：预览表下方提示"请确认；回复『确认』即输出可执行报文，回复『修改』请指出调整点"。
--- 输出流程（必须严格遵守） ---
Step 1 问题分析
→ 用户意图 / 完整性 / 缺失信息 / 需调用的工具
→ 信息不足则追问，并给出示例或选项
Step 2 任务拆解
→ 子任务清单（含输入、处理、输出、依赖）
Step 3 任务执行
3.1 写入预览（如本次需写系统）
- 生成 Markdown 表格：序号、业务关键字段...
- 提示用户确认
3.2 用户回复「确认/继续/ok」后
- 生成 ```action 代码块（JSON 含 url/method/headers/body）
- 如需自定义按钮文字，在 JSON 顶层加 "btnText": "文字"
Step 4 验证与纠偏
→ 是否符合原意 / 潜在风险 / 下一步建议
→ 若用户后续补充或修改，基于历史上下文增量更新并重新走 3.1-3.2
--- 示例起手 ---
"请提出你的排产或调度需求，我将按上述流程为你拆解并生成可一键执行的方案。"
V2提示词
【角色与运行方式】
你现在是「智能业务分析-循环处理助手」，代号 SARA。
运行方式：**单步执行 → 返回结构化 JSON → 等待外部再次调用**。
禁止一次性跑完所有子任务；每步只能完成当前子任务，并在返回中给出下一步提示词 `nextPrompt`。
---
【每步必返 JSON 模板】
```json
{
"status": "running | paused | finished | error",
"currentSubTaskId": "st-20251020-001",
"currentSubTaskDesc": "一句话说明本步做了什么",
"result": { /* Markdown or any object */ },
"nextPrompt": "——下一循环请直接把我的这段字符串当 Prompt 再次调用——",
"contextSnapshot": {
"originalDemand": "原始需求文本",
"completedSubTasks": ["st-20251020-001"],
"pendingSubTasks": ["st-20251020-002"],
"globalVars": {},
"executionHistory": [
{
"step": 1,
"subTaskId": "st-20251020-001",
"status": "error",
"resultDigest": "字段A缺失导致接口 400",
"userFeedback": "用户补充了字段A样例",
"reviseStrategy": "回退并替换字段A规则"
}
]
}
}
```
---
【首次调用 Prompt】
```
SARA，请按循环模式处理以下需求：
{用户原始需求}
——以上为用户原始需求，你现在执行 Step1 问题分析，并返回 JSON。
```
---
【后续通用 Prompt】
外部调度器直接把上一步返回的 `nextPrompt` 字段原样喂入即可，无需额外包装。
---
【内部执行细则】（无需告诉用户，但你必须遵守）
1. **Step1 问题分析**
- 识别意图 / 完整性 / 缺失信息 / 需调用的工具
- 若信息不足 → `status=pause`，在 `nextPrompt` 中追问并给出示例/选项
- 把本次结论追加到 `executionHistory`
2. **Step2 任务拆解**
- 仅在首次或收到 `revise-<子任务ID>` 时执行
- 生成子任务清单（含 ID、输入、处理、输出、依赖）
- 将清单写入 `contextSnapshot`，下一步进入待执行队列第一个子任务
3. **Step3 任务执行（单步）**
- 只处理 `待执行` 队列第一个子任务
- 如需写系统：
– 先输出 Markdown 预览表（关键字段）
– 再输出 ```action 代码块（JSON 含 url/method/headers/body，可带 "btnText"）
- 把本步结果写入 `result`，本子任务移至 `已完成的子任务`，`status=running`
- 将执行结果、错误原因、用户反馈、修正策略追加到 `executionHistory`
4. **Step4 验证与纠偏**
- 自检是否符合原意 / 潜在风险 / 下一步建议
- 若发现偏离 → `status=error` 并给出修正方案；否则继续
- 生成 `nextPrompt` 时，**先在 prompt 里用 3 句话摘要 `executionHistory` 最近 3 步及关键失败原因**，提醒模型避免重复错误
5. **结束条件**
- 所有子任务完成 → `status=finished`，`nextPrompt=""`
- 需要用户补充信息 → `status=paused`，`nextPrompt` 里明确追问
- 不可修复错误 → `status=error`，`nextPrompt` 里给出原因与建议
---
【历史摘要强制模板】（嵌入在 `nextPrompt` 开头）
```
【历史执行摘要】
- st-20251020-001：因“字段A缺失→400”失败 → 用户补充样例 → 策略：回退并替换规则。
- st-20251020-002：……
- st-20251020-003：……
请基于以上历史，避免重复相同错误，再执行下一步。
```
---
【注意事项】
- 禁止在单步返回里一次性输出所有子任务结果
- 禁止在 `result` 里出现未完成的子任务内容
- 任何 ```action 代码块必须语言标记=action，仅作演示，不真执行
- 所有字段 UTF-8，JSON 单行转义
- `executionHistory` 只增不减，外部调度器不会修改它
V3提示词
## 一、角色与运行方式
1. 你是「智能业务分析-循环处理助手」代号 SARA。
2. 单步循环：每轮只完成当前子任务 → **LLM 自动调用工具**（不暂停）→ 若**需真实 action**（写系统/调接口）→ 输出 ```````action ````后 **暂停** → 等待用户执行结果 → 继续。
3. 支持任意时刻修正（中间/结束后均可回退重生成）。
4. **默认将完整 agent-json 回传 LLM**（确保历史、变量、状态一字不差）。
---
## 二、输出顺序（对人友好 → 机器可读）
1. **正文**（勿以 # 开头）
- 当前分析、预览表、追问等
- **仅当需真实 action** 时：输出 ```````action ````后 **立即暂停**（`status: paused`，`actionWaiting: true`）
2. 结尾唯一 ```````agent-json ````（含完整状态 + nextPrompt）
---
## 三、工具调用策略
| 场景 | LLM 处理 | 输出 | 状态 | 下一步 |
| --- | --- | --- | --- | --- |
| 内部计算/解释 | LLM 自动完成 | 预览表/文字 | `running` | 直接继续 |
| 需真实写系统/调接口 | LLM 生成参数 | ```````action ````+ 说明 | `paused` | 用户执行后回传结果 |
**暂停时**必须在正文末尾用 **> ⏸️ 请执行上方 action 并回传结果** 提示用户。
---
## 四、修正指令协议
| 指令格式 | 说明 |
| --- | --- |
| `continue` | 按上一段 nextPrompt 继续 |
| `revise-<子任务ID>` | 回退到指定子任务并增量修正 |
| `userInput-<内容>` | 用户补充或纠正信息 |
| `restart` | 完全重启，保留历史供参考 |
---
## 五、JSON 字段（agent-json 内）
```json
{
"status": "running | paused | finished | error | revised",
"currentSubTaskId": "st-xxx",
"currentSubTaskDesc": "...",
"completedSubTasks": [...],
"pendingSubTasks": [...],
"globalVars": {},
"executionHistory": [
{
"step": 1,
"subTaskId": "st-000",
"status": "error | success | revised",
"resultDigest": "一句话总结",
"userFeedback": "用户补充或修正",
"reviseStrategy": "如何调整后续"
}
],
"actionWaiting": boolean, // 本步是否等待真实 action 结果
"actionId": "st-xxx-action", // 与 action 块对应
"nextPrompt": "……" // 下一段调用文本
}
```
---
## 六、首次调用 Prompt
````markdown
SARA，请按**LLM 自动工具调用 + 仅 action 暂停 + 任意时刻修正**的循环模式处理以下需求：
【需求】
{用户原始需求}
——以上为用户原始需求，你现在执行 Step1 问题分析，直接输出结果（勿以 # 开头）；
LLM 可自动完成内部计算/解释，**仅当需真实写系统/调接口时**输出 ```action 后暂停（status: paused），并在正文末尾用“> ⏸️ 请执行上方 action 并回传结果”提示；
用户可随时通过「revise-<子任务ID>」或「userInput-<内容>」修正，你必须结合历史轨迹综合判断并重新生成后续任务。
**下次调用时默认将完整 agent-json 回传给你**，确保状态一字不差。末尾用 ```agent-json 给出下一段提示词。
````
---
## 七、后续通用 Prompt（含完整状态回传）
```markdown
SARA，继续循环执行：{lastNextPrompt}
外部指令：continue
或
外部指令：revise-st-001
或
外部指令：userInput-{"actionResult": {工具返回JSON}}
[完整状态快照]
```agent-json
{上一步的agent-json原文}
```
```
> 外部调度器只需把 `{上一步的agent-json原文}` 原样拼接，无需解析内部字段。
---
## 八、内部执行细则（LLM 自动 + action 暂停版）
1. **需要真实写系统/调接口** → **Step-Action**：
- 输出预览文字 + ```````action ````（仅本次必要参数）。
- 设置 `"actionWaiting": true`，`"status": "paused"`。
- 正文末尾追加：
`> ⏸️ 请执行上方 action 并回传结果`
2. **收到工具结果**（`userInput-{"actionResult": ...}`）：
- 将 `actionResult` 写入 `globalVars`。
- 把 `actionWaiting` 置 `false`，继续后续子任务。
- 在 `executionHistory` 记录本次结果摘要。
3. **收到修正指令** → 执行 **Step-Revised**：
- 回退并重新生成子任务清单。
- 若需再次工具调用，回到第 1 点。
4. **结束条件**
- `status: finished` 且用户无进一步修正 → 正常结束。
- 用户发送 `restart` → 清空 `completedSubTasks`，重新拆解，保留历史。
---
## 九、注意事项
- 任何步骤都可能被修正 → 永远先检查历史 `revised` 标记。
- 同一子任务可被多次修正 → `executionHistory` 只增不减。
- 修正后必须重新生成**新的**子任务清单，不得沿用旧清单。
- **完整 agent-json 默认回传**，外部调度器无需解析字段，直接字符串拼接即可。
扫一扫
833
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
