AI 对话式配置调研 — 自然语言引导生成 Agent 平台配置

日期：2026-08-18 · 触发：用户提出「像与 AI 对话一样配置平台」（非固定弹窗向导，而是自然语言来回、AI 主动引导追问） 现状：已交付「弹窗式 4 步向导」（docs/api-contract.md §4.10，零 LLM 依赖）——保留为确定性兜底；本文调研真正的 AI 对话式配置是否值得做、怎么做。 配套：docs/agent-platform-architecture.md（ADR）· docs/api-contract.md §4.10（已做弹窗版契约）· docs/issues-log.md [08-18]（模型配额教训）

---

一、核心结论

值得做，但要分层：LLM 只做「意图理解 + 草稿生成」，不做「直接落库」。

用户自然语言 ──► LLM 理解意图 ──► 结构化配置草稿(JSON) ──► 前端预览/用户确认 ──► 复用现有校验端点原子落库
                     （对话状态机）        （不落库）             （HITL 确认）      （与弹窗版同链路）

关键取舍：

1. LLM 与落库解耦——LLM 生成的是「配置草稿」，永远经用户预览确认后才写库（复用 §4.10 的 POST /admin/chat/config 原子校验）。这同时守住「配置是生产真相源」和「模型配额 429 只影响体验不影响数据」两条底线。
2. 对话状态机是工程核心，不是 LLM 自由发挥——用「收集 → 追问 → 草稿 → 确认」的有限状态机，LLM 只负责每轮的意图提取和自然语言回复，结构由状态机保证。
3. 与已做弹窗版互补——弹窗版可退化为 AI 对话的「兜底模板」（AI 生成草稿后，用户可切到弹窗版微调）。

---

二、业界做法（2026 实测信息）

1. 腾讯云 ADP 4.0「Claw 模式」——一句话生成 Agent（最接近的参照）

• 做法：一句话生成 Agent，一键接入业务系统。用户自然语言描述需求 → 平台生成「Agent + 工作流 + 工具接线」的生产级配置草稿 → 预览确认后落库并可一键嵌入现有系统（腾讯云 ADP 4.0 发布、ADP 智能工作台）。
• 借鉴：①「一句话生成 + 一键接入」的产品话术与交互；②生成的是草稿（生产级、可审计），不是黑盒直写；③配置生成后与既有系统（表单页）互通。

2. Coze / Dify / n8n —— 低代码平台的配置心智

• Coze/Dify 偏「模板 + 分步表单 + 可视化编排」，n8n 偏「节点连线」；三家均以结构化配置为主，对话式（自然语言生成 workflow）多为「AI 辅助预填」而非全自动（低代码平台深度解析、四大开源方案场景适配、Agent Builder vs n8n/dify/coze）。
• 借鉴：业界共识是「AI 生成草稿 + 人审 + 可视化微调」三段式，纯对话全自动配置尚未成为主流——验证了我们的「草稿 + 确认」设计。

3. Claude Code 生态 —— 配置生成器（贴近「配置即代码」）

• cc-rig：选框架 + 工作流 → 生成完整项目配置（CLAUDE.md/agents/commands/skills），是「对话式配置生成」在 CLI 场景的落地。
• claude-config-generator skill / agent-builder skill：以 skill 形式提供「按需求生成配置」能力。
• 借鉴：「配置生成器」作为独立可复用能力（而非写死进页面），生成物是文本/结构化文件，人审后生效——与我们的「草稿 JSON」思路一致。

4. 企业 Agent 管理平台（Xurrent / Sema4.ai / BlueNexus 等）

• 2026 Q2 多家强化「自然语言描述 → Agent 配置」Agentic AI: Xurrent's Q2 2026、Sema4.ai 平台升级、BlueNexus。
• 趋势：对话式配置是 2026 企业 Agent 平台的标配方向，但都强调「人审 + 可回退」。

---

三、方案设计（针对本项目）

3.1 总体架构

┌───────────────────── 前端（B 端）─────────────────────┐
│  对话面板（聊天式 UI，非弹窗表单）                       │
│   ├─ 消息流：用户自然语言 ↔ AI 回复（追问/确认/解释）      │
│   └─ 配置草稿预览卡：实时展示「将写入的 target/scenario/  │
│                      override/tools/knowledge」          │
└──────────────────────┬──────────────────────────────────┘
                       │ POST /admin/chat 消息（含会话上下文）
┌──────────────────────▼──────────────────────────────────┐
│  后端对话服务（新模块 app/chat/）                        │
│   ├─ 会话状态机（Session）——收集/追问/草稿/确认 四态       │
│   ├─ LLM 意图提取（结构化输出）：需求 → 配置字段 JSON       │
│   ├─ 草稿组装器：JSON → 现有 upsert 请求体（复用校验）      │
│   └─ 落库：确认后调现有端点（§4.10 原子链路）              │
└──────────────────────────────────────────────────────────┘

3.2 对话状态机（核心）

IDLE ──用户描述需求──► COLLECTING（收集字段）
                        │ 缺 target 形态？→ 追问「产出什么？公众号/技术周报/短视频？」
                        │ 缺流程角色？  → 追问「要不要 research 检索环节？」
                        │ 缺资源？      → 追问「挂哪些工具/知识库？可建议默认」
                        ▼
                     DRAFT（生成草稿 JSON + 自然语言摘要）
                        │ 用户确认/修改意见 → 回 COLLECTING 或直接修订
                        ▼
                     CONFIRMED（前端展示完整清单）
                        │ 用户「确认落库」
                        ▼
                     APPLIED（调 §4.10 原子落库，返回写入清单）

• 每轮 LLM 输出：{ intent, extracted_fields, question?, draft? } 结构化 JSON（强制 schema，参照现有 review 强制 JSON 的做法）。
• 状态机保证结构，LLM 只填内容——字段缺什么、该问什么由状态机决定，LLM 负责把用户口语映射到字段。

3.3 关键设计决策

决策	选择	理由
LLM 是否直接落库	否，只生成草稿	配置是生产真相源；复用 §4.10 原子校验；模型 429 只影响生成不影响数据
会话状态存哪	服务端内存 dict（session_id → 状态），无新表	轻量；会话短生命周期；重启丢失可接受（MVP）
意图提取用结构化输出	是（强制 JSON schema）	与 review 节点同模式，可校验、可降级
生成 prompt 由谁写	状态机给骨架 + LLM 按 target/角色补全	避免 LLM 自由发挥产生不可控 prompt
与弹窗版关系	弹窗版作兜底模板	AI 生成草稿后用户可切弹窗微调；两者落库链路一致
模型配额 429	对话生成失败 → 提示 + 降级到弹窗版	issues-log [08-18] 教训：fallback 保可用不保质量

3.4 落地路径（分期）

Phase 1（MVP）——✅ 已实施 2026-08-19

• 后端：POST /admin/chat/session + /session/:id/message + /session/:id/apply（会话状态机 + LLM 意图提取，契约 §4.11；复用 deps.llm）
• 前端：聊天式对话面板（消息流 + 已收集字段 + 草稿预览 + 确认落库），总览页入口
• 验收 ✅：一句话「我要技术双周报，配 research+write+review+publish，挂 web_search」→ LLM 直接生成草稿 → 确认落库 → B 端可见（端到端实测通过）
• 实测发现：LLM 会规范 target 命名（tech_biweekly_report，优于规则式 fallback 的 new_config）；规则式 fallback（LLM 不可用）靠关键词提取 roles + 字段齐全即进 draft

Phase 2（增强，待做）

• 配置解释：AI 在对话里解释「为什么这样配置」「覆盖优先级如何生效」（做法 C 语义可视化）
• 增量修改：对已有配置「加一个知识库 / 把 write 换成 strong 档」等自然语言增量指令
• 多轮修订：确认前支持「改成 3 个角色 / 不要 research」等修改指令回 COLLECTING

---

四、风险与对策

风险	影响	对策
模型配额 429（强档）	对话生成不可用	① 对话用 fast 档（意图提取任务不重）② 失败提示 + 一键降级弹窗版（issues-log [08-18] 教训）
LLM 生成非法配置	落库失败	草稿永远走 §4.10 原子校验；失败回显错误让 AI 修正
用户口语模糊	草稿偏离意图	状态机强制追问缺失字段；草稿预览卡让用户确认
会话状态内存膨胀	内存泄漏	session 带 TTL（如 30 分钟过期清理）
与弹窗版功能漂移	两套入口不一致	共用同一落库端点与校验；弹窗版为兜底模板

---

五、结论与建议

1. 值得做，业界（腾讯云 ADP「一句话生成」、Claude 生态配置生成器、2026 企业 Agent 平台趋势）已验证方向。
2. 形态是「聊天 UI + 状态机 + 草稿确认」，不是弹窗表单——已做的弹窗版保留为兜底模板与落库复用。
3. LLM 与落库解耦是底线：LLM 只生成草稿，确认后才原子落库，模型配额只影响体验不影响数据。
4. 建议先 Phase 1 MVP（会话状态机 + LLM 意图提取 + 对话面板 + 复用 §4.10 落库），验收「技术双周报」用例；跑通后再评估 Phase 2（增量修改、配置解释）。
5. 实施前按项目纪律：开 feature_vX.Y_chat_config 分支、契约先行、TDD（对话状态机可脱离 LLM 用注入的「意图提取器」单测，LLM 部分走 smoke test）。

本调研仅为决策输入，未实施。落地前应更新 docs/version-plan.md、写迭代记录、对齐 ADR。