Business Perspective · 现在 vs Agent 化

PackHorizon
报告生成流水线
为什么要改

不讲代码 · 只讲业务感受——用户等多久 · 能不能中途看到进度 · 出错怎么办 · 运营能不能干预方向 · 未来能不能加"重新出这套图"这种功能。

结论:现在是一根绳子拽到底,agent 化后是几个工种并行接力

串行 workflow Multi-Agent 编排
现在
14分钟
单份报告平均耗时(中位数)
Agent 化后
6 方向图并行 + 深化并行
01 · Timeline Comparison

用户点"生成"后 · 系统内部到底在忙什么

每一格是一步智力活。现在的问题:后端 4 步(深化 6 方向 · 出图 · 对比 · 装配报告)本来彼此不用等,但代码里是硬串行,一步接一步排队做。 Agent 化后:同一时间多个"工种"并行开工,总时长压掉一半以上。

现在
串行
顾问对话(3~10 min · 用户输入决定)
装配
情报(联网)
定位
文案边界
发散 12-18
总监选 6
6 方向深化(1 次调用)
出图
新旧对比
装配报告
14 min
+ 对话
Agent 化
并行
顾问对话(3~10 min · 一样)
装配
情报 ‖ 定位 ‖ 文案边界(3 事并行)
发散 12-18
总监选 6
6 方向深化(6 agent 并行)
6 图并行 ‖ 新旧对比
装配报告
6 min
+ 对话
顾问对话(intake-dialogue agent · 灰虚线段)两版一样 · 用户输入速度决定 · 不算在生成时长。
生成时长省 ≈ 8 min / 单份 · 57% 缩短 · 主要来自"6 方向深化并行"+"6 图并行 & 对比并行"
顾问对话(pre-workflow · 用户输入速度决定)
装配(系统步骤)
AI 分析
发散 / 情报
总监收敛(选 6)
出图
新旧对比(可选)
装配报告
斜纹 = 内部并行执行
02 · Live UI Comparison · 用户端界面

用户点了"生成"之后 · 屏幕上到底看到什么

两张真实感的界面 mockup。左边是现在——转圈 + 百分比,黑盒 14 分钟。 右边是 Agent 化后——每个 agent · 每次工具调用(联网搜索 / 生成图片 / 写文案 / 装配报告)都实时打出来,像看厨房出菜。

现在 · Simple Progress
packhorizon.com/report/rp_9k2f
PackHorizon
您的报告正在生成中
预计还需 8 分钟,请勿关闭页面
42% 已耗时 05:53
当前阶段:AI 正在深入分析
剩余约 08:07
···
用户只知道百分比和一句笼统状态。挂了显示"生成失败请重试" · 前 42% 白跑,200 积分不退。
packhorizon.com/report/rp_9k2f/live
无糖气泡水 · 报告生成中 · run_9k2f2b · V36
已完成 8/11 步 已耗时 4:12 预计剩余 ~2:30
顾问装配情报定位合规发散总监设计师×6出图×6对比报告
Agent Status11
顾问对话5:24 · 4 轮
装配基线0:03
情报研究员1:32
品牌顾问0:48
文案合规员0:36
创意员1:04
设计总监0:29
设计师 × 64/6
图片模型 × 6
新旧对比员
报告总监
Live Activity Feed39 events
-05:24用户:我要给一款无糖气泡水做包装,主打 25-35 岁轻健康人群
-05:22顾问 agent:好的。包装形态是易拉罐 / 玻璃瓶 / 其他?
-04:48用户:330ml 易拉罐,SKU 3 种口味
-04:45顾问 agent:目标销售渠道是电商为主还是精品超市?有旧包装或竞品参考吗?
-02:16用户:电商 + 精品超市 · 上传 1 张 logo 和 2 张竞品图
-02:14顾问 agent:字段齐全,弹出确认卡...
-00:12顾问对话 · 完成 · 4 轮 · confirmation 已确认 · 素材 3 份
00:00run_9k2f2b 启动 · V36 · direction-contract-v3
00:03装配基线 · 已就绪 · 4 素材 · 1 logo
00:06情报研究员启动
00:11调用工具 web_search · "无糖气泡水 中国市场 竞品"
→ 返回 8 条 · 含元气森林/清泉出山/汉口二厂/nomo/Vinut
00:23调用工具 web_search · "sparkling water package design 2026"
→ 12 条国际参考 · 含 waterloo/spindrift/liquid death
00:41调用工具 web_extract × 5 · 抓竞品官网 hero
01:38情报研究员 · 完成 · 5 竞品 + 3 趋势 · gate=pass
01:38并行触发: 品牌顾问 + 文案合规员
01:42品牌顾问 · 思考 · 25-35 岁轻健康人群 · 差异化切入点
01:44文案合规员 · 分流品类 · 饮料模板 · 检查配料/净含量/低糖表达
02:26品牌顾问 · 完成 · 定位+目标用户+差异化
02:14文案合规员 · 完成 · frontCopy 白名单 12 条
02:26创意员启动 · 目标 12–18 概念覆盖 10 路线
03:12已生成 15 概念:符号识别 3 · 原料证据 2 · 材质 3 · SKU 系统 2 · ...
03:30创意员 · 完成 · 15 概念池 gate=pass
03:30设计总监启动 · 100 分制评分
03:41评分:商业转化 25 · 视觉资产 25 · 品类渠道 20 · 可制造 15 · 跨语言 15
03:53锁定 direction-1(主推)· direction-2 3 4 5 6 · gate 合同 v3 pass
03:59设计总监 · 完成 · 6 方向 · 前 3 included / 后 3 paid
03:59并行 fan-out 6 sub-agent · designer-1 ~ designer-6
04:00设计师-1 · 深化 direction-1 · 包装结构+字标+材质
04:00设计师-2 · 深化 direction-2 · 撰写 260 字英文 imagePrompt
04:00设计师-3 · 深化 direction-3
04:08设计师-3 · 完成 · 主视觉 brief + imagePrompt 280 字
04:09设计师-1 · 完成
04:11设计师-2 · 完成
04:12设计师-4 · 进行中 · Claude Sonnet 5 · 深化材质与工艺细节...
6 方向预览 · 主推图 30 秒后开始生成
#1主推
brief
#2included
brief
#3included
brief
#4写 brief
4/6
#5paid
排队
#6paid
排队
每次 web_search / web_extract / LLM 调用 / 图片生成都实时打进 activity feed · 每个 agent 卡片有 done / 进行中 / 排队 三态。挂了从 checkpoint 秒续,不重跑前面。
Activity Feed · 图标说明
Run 启动 · workflow_run 起点 · 记录 prompt 版本 / 合同版本
web_search / web_extract · 联网工具调用 · 抓竞品/参考真实网页
LLM 调用 · AI 思考中 · 打点带 token/model 信息
设计师 fan-out · 6 个 sub-agent 并行深化不同方向
image_generate · 调图片模型 · 主推优先 · 其他异步
Gate 校验 · schema + business gate · fail 触发 repair loop
并行触发 · fan-out 到多个独立 agent · 关键性能来源
Agent 完成 · 输出落 stage_artifacts · 触发下游
03 · Business Scenarios · 6 场景对比

6 个真实业务场景 · 现在 vs Agent 化的体感差异

不是抽象的架构好坏 · 是下面这 6 类具体情况下,用户 / 运营 / 客服的实际体验差多少。

1
用户点"生成"后要等多久
USER EXPERIENCE · 单份耗时
现在

12~16 分钟(中位数 14)

只能看进度条从 1% 爬到 100%。中间任何一步慢,整个报告都要跟着等 —— 因为下一步一定在等上一步的结果。

体感:从"扔进黑盒等 14 分钟"变成"看到一队人在给我干活"。等待焦虑显著下降。
2
中途某步 AI 出错怎么办
FAILURE RECOVERY · 兜底能力
现在

报告跑到第 9 步(出图)失败 = 前 8 步全部作废,从头再来

已经跑好的品牌情报、6 个方向,统统丢掉。用户看到"生成失败请重试"。
已扣积分不自动退。

体感:失败率不变,但"失败带来的浪费"从 14 分钟砍到 30 秒。用户等到成品的概率显著上升。
3
运营能不能在中途干预方向
HUMAN-IN-THE-LOOP · 人工介入
现在

不能。系统一旦启动就跑到底,运营只能事后打回让用户重出。

比如总监 AI 挑了 6 个方向,但运营看第 2 个明显走偏,只能等报告出完再说。

体感:从"AI 一条道跑到黑"变成"关键路口能踩刹车"。开出高端服务的可能性。
4
用户想"图不满意 · 重出一张"
PARTIAL RERUN · 局部重跑
现在

有"重生成第 X 张"按钮,但走的是另一条特殊代码路径,跟主流程逻辑分叉 —— 出过几次 bug。

用户要重新出报告全部内容?整份 200 积分重跑,前面的策略分析白算。

体感:从"重跑 = 全砸"变成"哪里不对改哪里"。给"重生成"功能更多想象空间。
5
要加个"新阶段"或"新客户类型"
EXTENSIBILITY · 加新功能的成本
现在

要加"礼盒专属流程"或"跨境 SKU 特殊阶段"—— 得动主循环代码 · 改 10 个阶段的分派器 · 各种 if-else。

结果:PM 想加什么都要排开发档期,新品类上线周期 2~4 周

体感:产品迭代速度 3~5 倍提升。PM 提需求不再听到"这个要动主循环,排下期"。
6
客服说"这份报告有问题"能查到吗
OBSERVABILITY · 事故排查
现在

要工程师翻 log · 手工拼时间线 · 猜是哪一步的 AI 出问题。一次排查 30~60 分钟

而且失败了就没了 —— 想复现同一个用户的报告基本不可能。

体感:客服工单从"我再帮您查一下"变成"我这就打开中间步骤看看"。排查时间从小时级降到分钟级。
04 · New Capabilities · agent 化后能开出的新业务

不是"改快点" · 是"能做以前根本做不了的事"

并行、可暂停、每步都能单跑 · 这三样合起来解锁一批新的产品形态。挑 4 个最容易赚钱的。

New Product
VIP 版 · 总监审核制

每 6 方向出完后暂停,由真人设计总监(或 vip 客户本人)扫一眼,确认后再进入深化 + 出图阶段。

可能定价:¥299~499/份 · 加 100 积分为 VIP 附加值

Retention
同项目二次生成 · 保留策略换风格

用户之前生成过的品牌策略、目标用户判断整套保留,只换发散阶段拿到 6 个新方向。省 60% 积分

可能定价:80 积分/份(vs 全新 200)· 提升用户复购

Efficiency
单图重生成 · 保留同方向 brief

用户看了主推图不满意,单独让"设计师 + 出图"两步重跑,策略不动。秒出而不是 14 分钟。

可能定价:30 积分/次 · 现在的重生成是全流程,可以这样优化

New Vertical
品类专属流水线 · 礼盒 / 跨境 / 药妆

每个特殊品类挂自己的合规检查员 + 特殊阶段(礼盒的仪式感检查 / 跨境的语言层级检查 / 药妆的功效边界检查)。

可能定价:作为 pro/vip 独有权益,或按品类差异化定价

05 · Risks & Mitigation · 不能只讲好听的

3 个必须提前想清楚的风险

Agent 版本是新建的独立模块 · 老 workflow 完全不动 · 界面加一个开关让用户主动 opt-in 试用。
所以不存在"迁移事故 / 灰度切换风险",风险主要在下面这 3 处。

Risk 01 · 两个版本长期共存的维护成本
同一套业务逻辑要维护两份

Prompt 改一次要同步到老 workflow + agent 版本两个入口。schema 变更 · 品类新增 · 合规规则更新都得改两遍,长期是双倍维护成本。

护栏:共用底层 prompt DB + 品类规则表 · 两个版本都从同一 DB 读 prompt · 只有编排逻辑不同。任何一版跑不稳,另一版兜底不影响业务。
Risk 02 · 并发放大 API 成本
6 张图并行 = 瞬时 6 倍供应商调用

老版本是串行,一次一个;agent 版并行后同一时刻要打 6 个 image API。供应商限流可能拦截,高峰时段可能不稳定

护栏:agent 版内置并行度上限可配置 + 供应商余额监控告警 + 主推同步、其他限流下降为异步补。
Risk 03 · 开发窗口撞产品迭代
新模块开发 4~6 周期间 · 主业务能不能持续迭代

过去 48 小时进了 6 个 commit —— 团队还在冲刺阶段。做 agent 新模块会占用一部分开发精力,可能拖延其他功能上线。

护栏:分阶段做(prompt 迁移 1 周 → spike 验证 1 周 → 全量 3~4 周),每阶段可停,主业务需求继续走老版不受影响。
06 · Agent Skill · 每个阶段到底怎么"能力包"化

一个 Agent = 7 件事的完整能力包

现在生产里一个 stage 只是 "prompt + 输出 schema" 两样东西 · 分散在 7 个不同文件里。 Agent 化后每个 agent 变成 一个 YAML 声明式定义,7 件事集中在一起——加新 agent = 加一个 YAML · 改 agent = 改一个文件。这才是 "能力包" 的真正含义。

01 · IDENTITY
身份 / 定位
这个 agent 是谁 · 扮演什么角色 · 边界在哪(能干什么 / 不干什么)
02 · PROMPT
三段 Prompt
system 定角色 + developer 定规则 + user 定当次任务(现有生产模式)
03 · INPUT
输入契约
需要从上游拿哪些字段 · 哪些是必需 · 哪些是可选 · 类型是啥
04 · OUTPUT
输出 Schema
JSON 结构 + 每字段类型 + 长度约束(如 imagePrompt ≥ 160 字)
05 · GATE
业务合同
schema 兜不住的业务规则(如"必须正好 6 个"/"recommended 恰好 1 个")
06 · TOOLS
工具箱
能调什么外部工具 · 联网搜索 / 品类规则查询 / 图片模型 / 品牌资产读取
07 · MODEL
模型 & 修复
用哪个 LLM · 温度 / 思考深度 · 失败重试策略 · repair loop 次数

11 个 Agent · 业务边界 / 独有工具 / 独有 Gate / 可调项

Agent 业务边界 独有工具 独有 Gate 可调项
intake-dialogue 只采集不判断 · 反问补齐 confirmation 字段 - confirmation 字段齐全 对话轮次上限 · 反问深度 · 智能默认值
source-intake 纯装配 · 无 LLM · 从 intake 域搬素材到 workflow 域 - requiredFields 4 项 无(系统步骤)
packaging-intelligence 品类竞争判断 · 唯一联网阶段 web_searchweb_extract minReferences: 3 · 每 ref 5 字段必填 检索深度 · 竞品数量 · 每维度必备字段
brand-strategy 商业判断 · 禁"高级 / 年轻 / 差异化" 空词 - requireSections 3 项(定位/用户/差异化) 目标用户深度 · 差异化切入维度
copy-compliance 文案白名单 · 品类风控 compliance-router requirePass: true 品类分流规则 · 每品类高风险表达列表
creative-exploration 发散 12–18 · 不筛选 · 覆盖 10 路线 - minConcepts: 12 · maxConcepts: 18 10 路线覆盖率 · 每 territory 长度约束
director-selection 收敛 6 · 100 分制打分排序 · 关键漏斗 quality-scorer 正好 6 · id 稳定 · tier 分布 · rec=1 且在前 3 5 维评分权重 · 主推硬规则清单
designer-directions 6 方向深化 · fan-out × 6 并行 - 继承 tier/id 禁改 · 每方向 14 字段 深化模块清单 · imagePrompt 长度约束
image-brief 出图 · 主推同步 · 其他异步 · fan-out × 6 image_generatelogo_reader 主推失败 = workflow fail size / quality / n / input_fidelity 参数
difference-review 仅 upgrade · 6 维新旧对比 - allowEmptyWhenNoLegacy 对比维度权重
report-presentation 装配 + 改稿 · 不重新发明策略 · final report-template 9 sections · 6 directions · rec ≥ 1 section 骨架 · conclusion 结构模板

Agent 化时必抽的 3 个新工具

现在这三样东西都硬编码在 prompt 字符串里,agent 化时抽成独立工具 · 让运营改规则不用改 prompt · 直接改 tool config。

Tool 01 · copy-compliance 用
compliance-router
品类分流从"prompt 里一大堆 if" 变成规则表查询工具。按品类返回该品类的合规约束清单。
现在:饮料/宠物/美妆/酒类风险模板 全在 developer prompt 里(2096 字)
之后:品类 查表拿规则 塞进 prompt · 品类新增只改表
Tool 02 · director-selection 用
quality-scorer
V36 起总监阶段的 100 分制评分从 prompt 描述变成显式打分函数。分数存 stage_artifacts 可回溯。
现在:商业 25 · 视觉 25 · 品类 20 · 可制造 15 · 跨语言 15 全在 prompt 里说,LLM 心里打分
之后:每方向调 scorer 返回 5 维分数 按 rank 选主推 · 权重可后台调
Tool 03 · report-presentation 用
report-template registry
9 sections 骨架 + 4 张表 columns 从 prompt 里硬编码的中文字符串变成模板 registry(YAML)。
现在:section 顺序 · 表格列名"渠道/展示/动作/风险" 硬写在 5867 字 prompt 里
之后:模板 registry 按 kind 拉模板 agent 只填内容 · 国际化天然支持
07 · Continuous Tuning · 后续持续调优体系

调什么 · 谁调 · 多久调 · 5 层 + 3 循环

Agent 化不是一次性交付 · 是每周都在跑的常态化工作流。调优的本质是"缩短反馈闭环" —— 从"发现问题"到"改完上线"的时间从现在的数天压到分钟级

调优 5 层 · 频率跟成本必须匹配

层级
频率
Owner
调什么
影响面
技术门槛
L1
每周
内容运营 / PM
Prompt 层 · 3 段 prompt 文本调整
单 agent
低 · 改 YAML
L2
双周
运营 + 工程
Tool Config · compliance 规则表 · scorer 权重 · report 模板
单 agent
低-中
L3
每月
产品 + 工程
Gate Rules · schema 兜不住的业务合同
单 agent
中 · 跑回归
L4
1-3 月
工程
Model Config · LLM 型号 · temp · reasoning · thinking level
单 agent
中 · 要 A/B
L5
每季度
架构 + 产品
DAG 编排层 · agent 顺序 · 新加 agent · 拆并行度
整个流水线
高 · 要迁移
为什么分 5 层?调优频率跟成本必须匹配。改一条 prompt 应该 5 分钟就能上线(改 YAML + PR)· 改一个 agent 拓扑要 2 周(要评估上下游 + 灰度)。混在一起就变成任何小改都要走大流程 → 谁都不想改 → 生产 V24 → V36 12 版全部靠手工 SQL 改的 drift 就是这样养出来的。

3 个调优循环 · 覆盖从事故到主动优化

1
Loop 1 · 事故驱动 · 快速反馈
用户 / 客服 说"这份怪"
从投诉进来到修复上线 · 目标缩到 2 小时内
1后台报告详情页 展开 agent trace(每 agent I/O + 耗时 + gate 全在)
21-3 分钟定位到出问题的 agent
3判断是 L1(文案)/ L2(规则)/ L3(gate)
4 PR review 灰度 1 周 全量
2
Loop 2 · A/B 实验 · 主动优化
"S3 输出太抽象,加示例应该更具体"
改 prompt 不靠感觉 · 用数据说话 · 1-2 周一轮 A/B
1建实验 exp_xxx · 变量 = 新老 prompt · 分流 50/50
2指标:主推方向 score 均值 · 重生成率 · gate fail 率
3跑 100+ 报告样本 · 1-2 周
4显著优 全量 · 无差异 保留 · 差 回滚
3
Loop 3 · 定期审查 · 健康度
周报 / 月报 / 季度回顾
主动发现异常 · 不等用户投诉才修
per-agent 成功率 · P95 耗时 · cost/token · gate fail 分类 · 异常标红
prompt 版本盘点 · 用户满意度趋势归因到具体 agent
DAG 拓扑评审 · 新品类要不要拆 agent · 死支流可以砍

必须建的 5 类观测(3 个 Loop 的数据基础)

M1
Agent 健康度看板
per-agent 成功率 / P50-P95 耗时 / token / gate fail 分类 · 异常标红
M2
Prompt 版本对比
V36 vs V37 · 同一批样本 · 核心指标 diff · Loop 2 靠它决策
M3
单份 Trace 详情
点开报告看每 agent 完整 I/O · gate 结果 · repair 次数 · Loop 1 定位用
M4
供应商成本
每 agent 每天 token / cost · 主推图 vs 备用图成功率
M5
满意度归因
打分 · 重生成率 · 客服工单 · 归因到具体 agent · L3-L5 决策依据
Case Study · 3 个 Loop 穿起来的完整案例
客服反馈:"报告 competitors 表格老是漏栏或内容重复"
这是一个真实场景 · 展示如何用 Loop 1 快速定位 → Loop 2 A/B 验证 → 沉淀成 CI 断言防退化。
Loop 1 定位
打开问题报告的 trace · 1 看到 report-presentation 输出 competitors 只有 3 列 2 追 reportContext.competitors 来源 = packaging-intelligence 3 打开 S2 输出:5 条竞品里 3 条 highlights 只有 1-2 个 4 根因锁定:S2 developer prompt 说"覆盖 5 维"但没给示例 · LLM 稳定在 3 维就停
决策
组合方案:L1 (prompt) 给 S2 developer 加 4 列完整示例 + L3 (gate) 加 每 competitorReport 必须 ≥ 3 highlights 作为保底
Loop 2 实验
建实验 exp_competitors_v37 · 20% traffic 走新版 · 100 份样本 · 跑 2 周 · 指标 = 4 列填满率 + 重生成率 + gate fail 率
结果
60% 92%
4 列填满率
18% 12%
重生成率
持平
gate fail 无新增
沉淀
1 skill YAML 更新 S2.developer 加示例段 · 2 gate_rules YAML 加 min_highlights_per_competitor: 3 · 3 CI 加断言:历史 S2 输出重跑仍能 pass 新 gate · 4 变更 log 记录版本 · owner · A/B 数据链接 · 5 客服知识库更新"竞品表漏栏"已在 V37 修复
08 · Roadmap · 3 阶段建新模块 · 老版本永远不动

并行开发 · 不替换老 workflow · 界面加开关让用户选

每一阶段都是独立可停的 —— 做完 Phase 0 也已经修了当前最痛的债,后续不做也不亏。老 workflow 永远不动,新模块跑不好用户还能用老的。

0
先修当前最痛的债 · 两版都受益
Prompt 迁移 + 图片合同拆分
1 周 · 零风险
  • 把生产 27/27 段 drift 修上 —— repo 跟生产对齐
  • Prompt 从 python 常量搬到 YAML 文件,以后 prompt 变更走 PR review
  • CI 检查:repo 里的 YAML 跟生产 DB 不一致就拦截
  • 图片合同 3 层拆成独立函数(给 Phase 1 铺路)
立刻收益 · 老 workflow 和未来 agent 版都能复用这套 prompt DB
1
小步试点 · 验证收益
Spike · 3 阶段试跑 LangGraph
1 周 · 低风险
  • LangGraph(业内最主流的 agent 编排框架)
  • 建一个独立目录 · 完全不动老 workflow 代码
  • 只搬前 3 步(情报 / 定位 / 文案边界)· 用同一份 intake 数据对跑
  • 决策点:省时超 30% 才继续 Phase 2
花 1 周拿到真实对比数据 · 再决定要不要花 4 周做全量
2
全量新模块 + 界面开关
Agent 版上线 · 用户 opt-in 试用
3~4 周 · 低风险
  • 11 个阶段全部搬到 agent 版 · 每 agent 自带失败重试
  • 6 方向并行 + 6 图并行(最大收益来源)
  • 用户端生成页加个开关:"使用新版并行引擎(实验)"
  • 老 workflow 保留 · 关掉开关就走老版 · 任何时候可以关
用户可选 · 老版永远兜底 · 新版有问题不影响业务
TL;DR · 一句话总结

现在:AI 报告像流水线上一根绳子拽到底 —— 一步接一步 · 中间挂了从头再来 · 用户等 14 分钟 · 运营不能干预 · 加新品类要 2~4 周。

Agent 化后:变成几个专业工种同时开工 —— 一队 AI 顾问 · 一队设计师 · 一队图片模型并行接力 · 每步进度可见 · 失败只重跑那一步 · 用户等 6 分钟 · 关键路口能踩刹车 · 加新品类 2~3 天。

怎么落地?Agent 版是新建独立模块 · 老 workflow 永远不动 · 生成页加个开关让用户 opt-in。先做 Phase 0(1 周 · 零风险,修当前 prompt drift 债 · 两版都受益)—— 不管后续做不做,这步都稳赚。做完再决定要不要走 Phase 1 spike 验证。

Next Step · 深入方案

已经形成一份可直接派活的实施方案
3 个月 · 3 阶段 · 19 个原子任务

每个任务包含 Owner / 时长 / 依赖 / 输入 / 输出 / 验收标准,可打钩执行。 含 7 里程碑 · 6 决策点 · 7 风险与护栏 · 附录含文件路径速查和老 workflow 黑名单。
核心约束:老 workflow 完全不动 · 用户端加开关 opt-in · 老版永远兜底

Doc agent-migration-implementation.md Version v0 draft Total ~3 months Risk
查看完整实施方案