飞驼 Agent 进化机制战略文档

定位: 内部战略 + 工程对齐文档, 非对外销售材料. 供 Claude (开发者) 和产品经理按此推进接口讨论和实现.

撰写背景: 2026-04-18 产品经理与 Claude Opus 4.7 战略讨论 (四方反向思考含 Sonnet critic / MiniMax 中国视角 / Agent A 全网学术调研 / Haiku meta-critic). 经 2026-04-19 重大战略校准后重写为整合版, 详细讨论过程归档入附录.

学术背书: 对齐 2025 两篇权威综述 arXiv 2507.21046 和 arXiv 2508.07407.

---

目录

1. 背景与起点
2. 拆解市面 "自进化" 产品本质
3. evolve 层次框架
4. 超越 LLM prompt 维度的系统级演化
5. 落地场景
6. 技术实现
7. 引擎层接口设计 (待接口讨论后回写)
8. 竞品情报摘要
9. 护城河分析
10. 风险与盲点
11. 产品叙事修正
12. 实施路线图
13. 附录

---

1. 背景与起点

1.1 讨论起因

v0.1.0 CHANGELOG 把 evolve 描述为:

"动态工具构建、Skill 学习、自我反思; 接口完备, v1.0 前完善完整能力环路"

产品经理认为这个描述低估了差异化意义, 要求重新讨论定位.

1.2 当前 evolve 包状态 (v0.1.0)

core/pkg/evolve/ 四个核心文件共 2050 行:

• ToolBuilder: 运行时工具构建 (Agent 自己写 bash 脚本)
• SkillLearner: 跨会话技能库 (保存工作流模板)
• SelfReflector: 自反思长期记忆 (lessons 累积)
• EvolutionStore: 产物持久化 (~/.flyto/evolve/{proposals,tools,skills,reflections})

三层安全: ApprovalFunc 人类审批回调 + SecretGuard 扫 API key + MaxPerSession 限速 + Observer 事件埋点.

1.3 本文档结论 (2026-04-19 战略校准后)

• evolve = 领域无关引擎 (core) + 行业专属消费层 (platform) + ML 真实数据反射器 的飞轮
• "领域无关" = 全领域支持, 不是 "不做任何行业". 消费层必须是行业专属的
• 反射器 = ML + 真实业务数据 (不是 LLM 文本反思), 评分依据可审计
• 垂直扩张路径: 飞驼云仓 → 仓储 → 物流 → 供应链, 参照 Salesforce/Palantir/滴滴飞轮
• 本文档是工程推进基准, 不是对外销售材料; 话术章节仅为内部口径一致

---

2. 拆解市面 "自进化" 产品本质

2.1 共性病根: 单向累积, 无反馈闭环

市面 "自进化 Agent" 的共同模式:

做了 → 记录 → 累积 (end)

真进化需要的模式:

做了 → 记录 → 业务评分 → 淘汰/加权 → 下次行为真的变了

选择压力 = "业务成功了没", 不是 "累积够不够".

2.2 三类典型产品定性

• Hermes 型 (Nous Research, 93k stars): 自己写便利贴. 不检查质量, 只增不减, 下次同问题还是照抄可能已失效的笔记
• Evolver 型 (国内开源): 查字典 + 填模板. 基因库 + 预制 prompt 模板, 不根据失败调权重, 本质是 if-else 的 LLM 调度器
• Voyager 型 (Minecraft 研究): 真让 LLM 写代码加入 skill library, 学术玩具无生产级安全边界

2.3 大模型厂反射形态: 全局反射

OpenAI / Anthropic 有反射机制 (A/B 偏好收集 + 用户评分上传), 但是全局反射, 不是本地反射:

维度	全局反射	本地反射 (Flyto)
目的	训练下一代模型	当前客户当前 Agent 变聪明
粒度	全网亿级用户汇总	本客户本仓 (张三补丁偏好 / 华东仓异常模式)
反馈周期	数月	秒/分 (fast loop) + 日/周 (slow loop)
本地回用	否	是
商业模式	卖 API / 标品	应用层引擎 + 垂直消费

叠加而非替代. Flyto 基于他们的模型运行, 再做本地反射.

2.4 四类竞争位置

按位置分类 (不点名具体产品):

位置	特征	Flyto 的差异
大模型厂	全局反射, 数月周期, 不下垂直	我们做本地反射, 秒/天周期
编排框架厂	只到多 Agent 协作层, 无业务反馈闭环	我们有 ML + 真实数据反射器闭环
国内大厂	停在模型层和编排层, 组织固化不下垂直	我们 1-2 年先发窗口
垂直 SaaS 厂	有数据无引擎, 产出专家系统	我们引擎 + 数据结合, 自进化

Flyto 是唯一同时具备引擎能力 + 垂直场景 + 真实数据反射器的位置.

---

3. evolve 层次框架

基于 TMS PDF 30 页 + 45 节深度分析, 把 Agent 参与的场景分成 4 个层次.

3.1 四层拆分

Level	场景	有 LLM 吗	反馈信号	evolve 适用
Level 1: LLM 辅助生成	报价配置导入、补丁、解释、SOP 抽取、波次建立	LLM 主力	校验器/仿真/采纳率/ML 预测	最佳
Level 2: LLM 辅助判断	包装解析、不确定性评估、可达性判断	LLM 参与	预测 vs 实际	可用
Level 3: 数值决策引擎	有效边际成本、配额控制、阶梯状态、均重池	纯数学	数据回流	引擎本身不适合, 参数可事后反射
Level 4: 实时链路	毫秒级承运商分配、规则直出	规则	对账	实时链不反射, 事后日志回放可反射

3.2 PDF section 45 的直接验证

PDF 原话: "系统确实使用了大模型, 但用在了正确的地方"

• 用于: 临时策略简化、报价文档解析、策略 DSL 草案、经营先验补丁、决策解释、对账解释 (Level 1-2)
• 不用于: 高频实时主分配、重量预测、有效边际成本、最终逐单决策优化器 (Level 3-4)

PDF 第十一部分 "策略智能化" 阶段正是 evolve 主战场.

3.3 反射器升级: ML + 真实数据 (2026-04-19 校准)

原定义: LLM-based 文本反思 (self-reflection + lessons 累积).

新定义: 反射器 = ML 模型 + 真实业务数据训练 + LLM 自然语言解释层.

评分依据是历史事实, 不是 LLM 文本反思:

Q: 为什么给 Y 承运商打 73 分?
A: 同承运商 + 同路线 + 同季节历史 1247 单准时率 83%
   近 30 天投诉 3 次 (工单 TK-2401-034 / 2401-089 / 2402-012)
   结算纠纷 1 次 (订单 ORD-A1B2C3)
   (数据源: 客户真实结算表 + 投诉工单 + 路由日志)

合规价值: 真实数据评分 > LLM chain-of-thought 文本解释, 更可审计.

3.4 实时链的事后反射

实时链当下不反射 (毫秒级要确定性), 但决策快照全留着 (PDF 31-33 节):

• dynamic_cost_view_snapshot
• carrier_execution_feedback
• carrier_settlement_feedback

LogReplayer 组件负责扫这些日志, 把当年决策 (评分 87) 与真实后果 (投诉 + 结算纠纷) 对齐, 反推该评分高了 20 分, 下次同承运商打分自动下调.

实时链与 LogReplayer 的关系:

• 实时链: 快 (毫秒) 但盲 (KPI 还没发生)
• LogReplayer: 慢 (日/月) 但准 (KPI 齐全)
• 两者互补, 不是替代

---

4. 超越 LLM prompt 维度的系统级演化

4.1 盲区修正

讨论初期曾把 "反射" 局限为 "下次 LLM 生成时把历史塞进 prompt". 这太狭窄.

真正可反射的维度远不止 prompt:

反射对象	反射机制	周期	示例
LLM prompt 注入	LLM 上下文拼接	秒/分	"张三对 X 客户偏高 22%" 塞进下次 prompt
ML 模型参数	ML 反射器	日/周	预测偏差累积 → 定时 retrain
规则引擎权重	ML 反射器	日	FinalDecisionScore 的 α/β/γ 自动校准
判断阈值	Bandit / RL policy	日	不确定性触发人工审核的阈值自适应
候选偏好	ML 反射器	周	过去历史 X 表现好 → 初始偏好 +10%
规则库清理	ML + LLM	月	N 条规则从未触发 → 建议删
候选数量	Bandit	周	之前出 5 个 3 个够了 → 下次出 3
评估器本身	MetaEvaluator	月	ML 预测器对冷链不准 → 自动收窄 confidence
缓存策略	规则	日	某类 prompt 结果稳定 → 加 cache
Agent 分工	ML 反射器	周	A 做任务 X 成功率低 → 下次 B 做
prompt 模板本身	LLM + ML	周	完整模板演化, 不只是注入变量

每个维度对应的演化机制不同: LLM 生成候选 / ML 反射器评分 / Bandit 选择 / RL policy 控制 / 规则 if-else.

4.2 时间尺度对应反射对象

毫秒/秒 : 不反射 (实时决策需要确定性)
秒/分   : LLM prompt 注入 (快反射)
分/时   : 候选策略/温度/路由调整 (LLM + Bandit)
日       : 参数权重/阈值/偏好校准 (ML 反射器)
周       : ML 模型再训练 / Agent 分工调整
月       : 规则库清理 / Bundle 结构演化
季       : 整个系统架构元反射 (MetaEvaluator)

4.3 黏菌哲学: 利用 LLM, 不对抗

不是补齐 LLM 缺点, 也不是对抗 LLM 缺点, 而是利用 LLM 特性.

LLM 特性	对抗派	利用派 (Flyto)
幻觉	更严 prompt 抑制	多样性来源 (采样池)
不确定	升温度=0 让它变死	探索能力来源
慢	硬扛	并行 + 便宜 evaluator
贵	缓存 / 小模型	LLM 生成 + 便宜 ML 评分

LLM 当高维采样器 + ML 做评分器 + evolve 做留存/淘汰 = 黏菌范式.

黏菌类比:

• 黏菌没有中枢神经, 每个点都在探索 + 收缩
• 成功路径被强化 (信息素), 失败路径萎缩
• 没有主控制器但能整体解迷宫

Flyto 对应:

• LLM = 大量探索节点 (高温采样)
• ML 反射器 = 环境反馈 (成本低但准)
• evolve 接口 = 留存/淘汰机制
• 整体涌现好结果, 不依赖单点最优

4.4 定义升级

• 之前: evolve = "让 LLM 在这次任务里越用越熟"
• 修正: evolve = "系统里一切可变参数的统一演化框架, 由 LLM/ML/Bandit/RL 协作推进"

---

5. 落地场景

5.1 判断场景是否适合 evolve 的 3 要素

同时满足三要素的场景都适合 evolve:

1. LLM 生成内容 (方案 / 补丁 / 解释 / 抽取结果)
2. 能被评判 (便宜 evaluator: ML / 校验器 / 仿真 / LLM critic / 人类)
3. 业务反馈 (对账 / 采纳率 / 实际 vs 预测)

数值计算、实时关键路径不适合.

5.2 TMS 场景全景 (PDF 映射)

场景	PDF section	Level	反射机制
建波次	-	1	LLM 5 方案 → ML 打分 → Top-2 变异 → 审批 → WMS 回流 → 校准
报价合同导入	20	1	LLM 3 YAML → 校验 + 仿真 → 审批 → 长反射对账 → 补缺项
经营先验补丁	27	1	LLM 3 变体 → 历史偏差校准 → 审批 → 实际 vs 预测 → 自动 correction factor
临时干预补丁	10	1	LLM 3 变体 → 校验 + 仿真 → 审批 → 补丁失效后验证异常率
冷启动新仓库	-	1	LLM 3 配置 → 相似仓参考 → 审批 → 累积数据后自动调整
决策解释生成	32	1	LLM 写解释 → 运营采纳率 + 客户反馈
对账异常根因	33	1-2	LLM 3 原因 → 运营定位方向 → 对应方向 LLM 加权
规则库自动清理	-	1	LLM 合并方案 → 历史仿真差异 <2% → 通过

5.3 代表性场景: 建波次

操作员说 "明天早班给 WH01 建 3 个波次":

第 1 步 (LLM 多方案):
  5 种角度 (SKU 聚类/目的地/尺寸/客户/混合) → 5 个方案

第 2 步 (ML 反射器评分):
  对 5 个方案给 fitness score (预测时长 + 预测异常率)
  评分依据: 历史同类波次真实完成数据

第 3 步 (进化):
  Top-2 (C 和 E) → LLM 各微调 3 个变体 → 再打分

第 4 步 (审批):
  最优方案交操作员 approve

第 5 步 (长反射, WMS 回流后):
  预测 4.5h vs 实际 4.8h → 系统记下偏差
  下次 LLM 出方案先看历史偏差 → 自动变保守

关键: LLM 不是一次出最优, 是 "多出几个让打分器筛".

5.4 代表性场景: 经营先验补丁

运营说 "明天 X 客户 3000 单大促":

第 1 步: LLM 生成 forecast_commitment_patch 草案

第 2 步: LLM 出 3 个变体
  A: confidence 85 (LLM 默认)
  B: confidence 70 (因为张三前 5 次偏高 22%, 系统后台校准)
  C: A + "延期到后天" fallback

第 3 步: 无便宜 evaluator (未来未发生), 操作员直接看
  界面提示: "你最近 5 次类似预测平均偏高 22%"

第 4 步 (次日实际):
  X 实际 2100 单 (不是 3000)
  系统记下 "张三对 X 客户预测偏高约 30%"
  不直接告诉张三, LLM 下次自动加 correction factor

第 5 步 (累积后):
  下次张三说 "2000 单活动" → LLM 自动补 "基于张三过往偏差估计更可能 1400 单"

妙处: LLM 不说教, 自己悄悄校准.

5.5 非 TMS 场景 (跨行业)

• Bundle 场景 prompt 演化 (跨行业 bundle 内 prompt 根据各行业反馈贴合)
• Skill 自动发现 (连续 N 次类似任务主动提议保存)
• Agent Teams 分工优化 (A/B 协作谁做什么根据历史)
• 工具选择偏好 (某场景 Bash 更常成功 → 优先推荐)
• 异常处理方案推荐
• 运营 SOP 进化 (反复手工干预同一问题 → 沉淀规则)
• 补货策略 / 排班 / 客服工单分类
• ML 模型监控报警阈值

---

6. 技术实现

6.1 LLM 多方案生成 (6 种做法)

做法 A (温度): 同一问题用不同温度 (0-1) 调用多次 → 不同松紧度方案.

做法 B (列举, 最常用): 一次 prompt 要求 "给我 5 种不同思路, 每种角度必须明显不同: 1. 按 X 2. 按 Y 3. 按 Z 4. 按 W 5. 你自己想一个" → 1 次调用拿 5 个. 最便宜.

做法 C (反驳自己): 多轮串行, 轮 2 要求 "前一个有什么问题再给一个不同的" → 多样性最好但慢.

做法 D (角色扮演): "扮演时效专家/成本专家/稳定性专家出方案" → 同一 LLM 戴不同帽子自然不同.

做法 E (不同约束): "必须 3h 完成 / 异常率 <2% / 成本最低 / 保底 >85%" → 4 个侧重 4 个方案. 对应 PDF section 29 线性加权公式.

做法 F (多模型): Claude + GPT + MiniMax + Qwen → 不同厂家偏好不同答案.

Flyto 推荐组合 (以波次为例):

第一轮: 做法 B + D 混合
  "扮演时效/成本/稳定/聚类 4 专家各出 1 个方案 + 加第 5 个自己想的"
  1 次 LLM 调用拿 5 候选

第二轮: 做法 A + C 混合
  Top-2 各用温度 0.7 微调 + "指出前一版问题并改进"
  每个派生 3 变体 → 新 6 候选

总计 11 候选, 4-6 次 LLM 调用.

6.2 评估器类型

评估器	适用	成本	质量
ML 预测器	波次效率、承运商结果、包装重量	低 (毫秒推理)	高 (有训练数据)
规则校验器	YAML 语法、schema 完整性	极低	高 (确定性)
仿真器	报价导入、补丁影响	中 (跑历史)	高 (真实数据)
LLM critic	内部一致性、多方案互评	中 (LLM 调用)	中 (self bias)
人类	最终审批	高 (时间)	最高 (但慢)

6.3 两层反射架构

                  操作员触发
                      ↓
            ┌─ LLM 生成候选 × 5 ─┐
            │                    │
            ↓                    ↓
         Evaluator          Evaluator ...
            ↓                    ↓
        fitness 5            fitness ...
            └──── 排序 ────┘
                  ↓
            Top-2 变异 × 3 → 再评分 → 最优输出
                  ↓
              操作员审批 → 执行
                  ↓
            业务 KPI 反馈 (日/月级)
                  ↓
     ML 反射器更新评分模型 + LLM 偏好权重

• 短反射 (fast loop): LLM 生成 → evaluator 评分 → 迭代 (秒/分)
• 长反射 (slow loop): 执行 → 业务 KPI → 调整 ML 权重和 LLM 偏好 (日/周)

两层结合才是真进化.

6.4 ML 反射器定位 (2026-04-19 核心升级)

ML 反射器不是局部工具, 是 evolve 的核心组件:

• 训练输入: 客户真实业务数据 (订单 / 结算 / 投诉 / 路由日志)
• 输出: fitness score + 评分依据的具体历史数据引用
• 合规价值: 评分有事实基础, 客户问 "为什么打 73" 可以直接指出历史数据 (同路线同季节 83% 准时率)
• 技术路径: 每个行业一个专属反射器 (飞驼云仓反射器 / 仓储反射器 / 物流反射器) + 引擎层统一接口

行业专属 small model (v0.5 引入): 基于 7-13B 开源模型 (Qwen/Llama) LoRA 微调, 注入行业术语和业务规则. 主模型 (Claude/GPT) 仍是主力, small model 处理高频场景降本.

6.5 局部 RL policy (v0.4 引入)

policy network 不是替代 LLM, 只学 "选哪个参数":

• Contextual bandit 选承运商 / 补丁阈值 / 审批层级
• RLAIF (反射器自己打分) 代替人类标注
• Shadow → A/B → 生产三步灰度

不做 end-to-end RL. 引擎架构仍是 "LLM 生成候选 + ML 评分 + 规则 gate + 人工审批", RL policy 只在参数选择这一层.

6.6 成本账

• 每候选 ≈ 1 次 LLM 调用
• 5 候选 ≈ 5 次调用
• MiniMax 约 2 元 / 次, Claude Sonnet 约 1 美元 / 次
• 十几块钱 / 美元得到一次决策演化

对比: TMS 波次规划错误可能导致几万到几十万运输成本偏差. 性价比极高.

6.7 冷启动策略

新客户/新仓库累积数据前:

• 选项 A: 默认参数 (保守但不精准)
• 选项 B: 相似客户迁移 (meta-learning, 学术 open problem, v3.0+ 研究级)
• 选项 C: 高频询问操作员偏好 (成本高但最准)

当前方案: A + C 混合, 有足够数据后转本地反射.

---

7. 引擎层接口设计

状态 (2026-04-18): v0.2+ 接口矩阵 9/9 delivered. 权威契约在 core/pkg/evolve/interfaces.go, 交付一览见 §7.4. 本章保留历史 Round 1/2/3 讨论脉络以解释设计演变 (合并 / 吸收), 每节末尾标注"当前状态".

7.1 Round 1: 四个核心接口

type Generator interface {
    Generate(ctx context.Context, input any, K int, opts ...GenOpt) ([]Candidate, error)
}

type Evaluator interface {
    Score(ctx context.Context, candidate Candidate) (fitness float64, breakdown map[string]float64, err error)
}

type FitnessSignal interface {
    Report(entityType, entityID string, score float64, context map[string]any) error
}

type SelectionPressure interface {
    AdjustWeights(histories []Record) (newPriors Weights, err error)
}

当前状态 (2026-04-18):

接口	状态	参考实现
Generator	delivered	core/pkg/evolve/generator_llm.go (LLMGenerator)
Evaluator	delivered	core/pkg/evolve/evaluator_impls.go (Func/Weighted/Rule)
FitnessSignal	merged → FeedbackChannel	core/pkg/evolve/feedback_channel_file.go
SelectionPressure	absorbed → ParameterEvolver	core/pkg/evolve/parameter_evolver_default.go

FitnessSignal 和 FeedbackSource (§7.3) 在实现时合并为单一双向通道 FeedbackChannel, 同一份数据两种访问模式 (push Report / pull Query) 合并减少 概念负担. SelectionPressure 的偏好权重调整和规则系数 / 阈值调整无本质区别, 合并到 ParameterEvolver 统一接口.

7.2 Round 2: 扩展系统级演化接口

type ParameterStore interface {
    Get(key string) (value any, version int, err error)
    Set(key string, value any, reason string) (newVersion int, err error)
    History(key string, limit int) ([]Change, error)
    Rollback(key string, toVersion int) error
}

type ParameterEvolver interface {
    Propose(key string, evidence []FeedbackRecord) (proposedValue any, confidence float64, err error)
    Apply(key string, value any, approved bool) error
}

type LogReplayer interface {
    Replay(from, to time.Time, filter FilterFunc) (<-chan Event, error)
    RegisterReflector(r Reflector)
}

type MetaEvaluator interface {
    AuditEvaluator(evaluatorID string, recent []PredictionActualPair) (
        accuracy float64,
        biasReport map[string]float64,
        suggestedAdjustments []Adjustment,
        err error,
    )
}

当前状态 (2026-04-18):

接口	状态	参考实现
ParameterStore	delivered	core/pkg/evolve/parameter_store_file.go
ParameterEvolver	delivered	core/pkg/evolve/parameter_evolver_default.go
LogReplayer	delivered	core/pkg/evolve/default_log_replayer.go
MetaEvaluator	planned (v3.0+ 研究级)	—

LogReplayer.Replay 签名从 Round 2 草案的 (<-chan Event, error) 调整为 error — 事件通过 RegisterReflector 注册的 Reflector push 分发, 避免 caller 自己起 goroutine drain channel. 演变理由: Reflector 本就是 push 式 event-driven 设计 (见 interfaces.go Reflector 注释).

7.3 Round 3: 数据源接口 (领域无关)

引擎只提供接口, 不假设数据源结构:

type DataSource interface {
    // 业务数据源 (订单 / 结算 / 投诉 / 路由日志)
    // 具体实现由消费层提供, 引擎只操作抽象接口
}

type LogSource interface {
    // 历史决策日志源, 供 LogReplayer 消费
}

type FeedbackSource interface {
    // 业务 KPI 反馈源 (对账结果 / 客户评分)
}

当前状态 (2026-04-18):

接口	状态	参考实现
DataSource	planned (platform 层)	—
LogSource	delivered	core/pkg/evolve/log_source_file.go
FeedbackSource	merged → FeedbackChannel	core/pkg/evolve/feedback_channel_file.go

DataSource (业务数据源, 订单 / 结算 / 投诉) 仍由消费层自行实现, 引擎不内置 默认实现, 对齐"数据接入边界" (见 memory project_architecture_decisions.md).

7.4 v0.2+ 接口矩阵交付一览 (2026-04-18)

权威契约: core/pkg/evolve/interfaces.go (10 接口 + 1 func type).

#	接口	参考实现	对应 Round
1	Generator	generator_llm.go (LLMGenerator)	7.1
2	Evaluator	evaluator_impls.go (Func/Weighted/Rule)	7.1
3	Reflector	reflector_impls.go + self_reflector.go	new
4	ApprovalFunc (func type)	evolve.go (Config.ApprovalFunc)	new
5	ParameterStore	parameter_store_file.go	7.2
6	ParameterEvolver	parameter_evolver_default.go	7.2
7	LogReplayer	default_log_replayer.go	7.2
8	LogSource	log_source_file.go	7.3
9	FeedbackChannel	feedback_channel_file.go	7.1 + 7.3 合并
10	ShadowRunner	shadow_runner_default.go	new

闭环 example (9 接口串联跑通): core/examples/evolve_closed_loop/main.go (commit 41805b6, baseline 1.0 → version 2 的 1.5, divergence 0.1736, shadow delta +0.105).

现有 ToolBuilder / SkillLearner / SelfReflector 保留为高层组件 (不改造为 通用接口), 与新接口矩阵并存. SelfReflector 实现了 Reflector 契约.

---

8. 竞品情报摘要

详细四方调研 (Sonnet critic / MiniMax / Agent A 学术 / Haiku meta-critic) 归附录 13.4.

8.1 核心信号 (三方或四方一致)

• MLOps 不做系统级演化 — 只做 drift 触发重训, 阈值是人配静态告警线
• 合规/审计/可解释是硬需求 — B 端必答题
• Credit assignment 是学术 open problem — 7 维参数同时动反事实归因极难
• 国内大厂组织固化给 Flyto 1-2 年先发窗口
• 学术底座 30-40% 已有 (Maestro/Artemis/Trace), 业务 KPI 闭环 0% 端到端

8.2 Haiku 综合判断

护城河 60% 有条件成立:

• 成立: 相比竞品 Flyto 是业界唯一端到端闭环的产品级实现方向. 学术 0% + 商业 0% + 开源 0%, 从 2025 论文盲区中来, 有先发优势
• 不成立: v0.1.0 实现深度仅三维 (工具/技能/反思), 规则系数/阈值/权重框架空, 合规工具链未装, credit assignment 无设计方案

---

9. 护城河分析

9.1 学术空白 (最强信号)

2025 两篇权威 survey (arXiv 2507.21046 和 arXiv 2508.07407) 明确把 Flyto 定位领域列为未覆盖区域. 不是 "没人想到", 而是 "credit assignment 是 open problem 没人解决了".

Flyto 填的是学术承认的真 gap.

9.2 合规优势: ML + 真实数据反射器 (2026-04-19 升级)

这是新战略下我们最硬的武器, 独立成节.

传统 AI 决策合规审计难点: 客户问 "为什么这次打 73 分", LLM chain-of-thought 是文本生成可能幻觉, 不算证据.

Flyto 反射器基于 ML + 真实业务数据训练, 评分依据是历史事实:

Q: 为什么打 73?
A: 同承运商 + 同路线 + 同季节历史 1247 单准时率 83%
   近 30 天投诉 3 次 (工单号 TK-2401-034 / 2401-089 / 2402-012)
   结算纠纷 1 次 (订单号 ORD-A1B2C3)

事实级的评分依据比文字解释可审计性更强. 这是 B 端 (金融/医疗/3PL) 硬需求, 也是 Flyto 相对通用 Agent 的差异化.

9.3 垂直飞轮 (2026-04-19 新增)

"引擎 + 垂直行业" 飞轮:

飞驼云仓数据 → 专属反射器 → 引擎能力提升 → 扩仓储行业
    ↑                                              ↓
    ← ← ← ← 仓储数据反哺引擎 ← ← ← ← ← ← ← ← ← ← ←

参照: Salesforce (CRM → Service → Marketing) / Palantir (军工 → 政府 → 企业) / 滴滴 (出租 → 专车 → 顺风 → 货运).

每个垂直行业:

• 真实业务数据训练专属反射器
• LoRA 微调行业 small model (云仓 7B / 仓储 7B / 物流 7B)
• 数据飞轮启动后竞争壁垒升高

9.4 位置护城河: 四类竞争中唯一的组合

位置	引擎	垂直数据	反射器	Flyto
大模型厂	✓	✗	全局	-
编排框架厂	✓	✗	✗	-
国内大厂	✓	部分	✗	-
垂直 SaaS 厂	✗	✓	✗	-
Flyto	✓	✓	✓	唯一组合

9.5 时间窗口

数据壁垒生效前的先发优势窗口 1-2 年:

• 国内大厂组织固化 (MiniMax + Agent A 两方验证)
• OpenAI/Anthropic 商业模式冲突 (不下垂直)
• 垂直 SaaS 厂补引擎能力需要技术积累

这不是工期预测, 是飞轮启动前后来者的追赶成本曲线.

9.6 真正技术挑战 (非护城河, 是未解问题)

1. Credit assignment — 7 维参数同时动反事实归因 (学术 open problem, v3.0+ 研究级)
2. 稳定性悖论 — 演化 vs 可预期冲突 (工程级, shadow mode + 学习率控制)
3. 冷启动 — 新客户累积数据前 meta-learning 无现成方案 (v3.0+)

解决它们 = 在学术领先领域建立第二重护城河.

---

10. 风险与盲点

10.1 Credit assignment

问题: 7 种参数同时动, 一个订单出错难归因.

策略: 分层组合.

• Shadow mode A/B: 新参数影子运行, 对比老版本
• 分层归因: 每次只改一个参数
• ML 反射器评分: 客观事实依据
• 一次演化一维 兜底, 不贪心

承认研究级, 归 v3.0+.

10.2 反馈信号质量

问题: 云仓 TMS 对账可能来自 ERP 延迟 / 货主失误 / 物流商抖动 / 季节异常, 不是 Agent 决策错.

策略:

• 信号设计文档 feedback_signal_design.md (领域无关, 通用抽象) 先于代码
• 信号清洗升级为 ML 反射器训练时自动学季节性, 不手写规则
• 置信度评估 (低置信度反馈降权)
• 延迟信号不参与 fast loop, 只参与 slow loop

10.3 稳定性悖论

问题: 客户要可预测, 演化天然引入漂移.

策略 (三层):

• 硬止血: 熔断器 + CAS 乐观锁 + Staging 表 + 影子表
• 软约束: ConvergenceValidator (参数变化率超阈值拒绝提交)
• 客户选择: 冻结模式 + 演化透明度面板

稳定性 SLO: 连续 N 次参数更新无显著漂移 = 稳定.

10.4 冷启动

问题: 新客户累积数据前参数演化有效性未知.

当前方案:

• 默认参数 + 相似客户迁移 + 操作员高频询问
• 跨客户迁移是 platform 层的事, 引擎提供迁移接口
• Meta-learning 归 v3.0+

10.5 客户 "可预期" 需求

问题: "自动演化参数" 对传统制造业 3PL 听起来是噩梦.

策略:

• 叙事不讲 "自进化", 讲 "越用越懂你的仓库" (详见 11.3)
• 演化默认保守 (低学习率), 激进客户可调
• 冻结模式 + 透明度面板兜底

10.6 工程复杂度

问题: 多维度参数空间同时演化复杂度爆炸.

策略:

• 一次一维, 依赖前一维度稳定后再加下一维
• v0.3 先做 "承运商评分" 一维
• v0.4 加 "补丁阈值" 维度
• 按 commit 数推进, 不按工期

10.7 数据不足 + 多租户隔离 (RL 路线新风险)

问题: 飞驼云仓初期数据量少, 反射器评分方差大; LoRA 微调不能混客户数据.

策略:

• 初期用模拟数据 + 相似客户数据启动, 真实数据到位后切换
• 多租户数据隔离由 platform 层保证, 引擎不做跨租户数据聚合
• 数据量达到阈值前反射器输出标注低置信度, 给人工兜底空间

10.8 模型漂移 + continual learning

问题: 业务规则/承运商/政策变化时模型失效, 重训频率是开放问题.

策略:

• 漂移检测: 预测 vs 实际偏差监控
• 定期增量 retrain (频率按行业节律, 由 platform 层决定)
• 重大业务变化事件触发强制 retrain

10.9 基座模型依赖

问题: LoRA 基于 Qwen/Llama 开源模型, 基座模型质量决定上限, 开源生态变化有风险.

策略:

• 基座模型解耦: 引擎层不锁定特定开源模型, provider 接口抽象
• 主模型 (Claude/GPT) 兜底: small model 不可用时 fallback
• 跟进开源生态 (Qwen/Llama/Mistral 等新版本)

10.10 RLAIF 评估器自指涉陷阱

问题: 反射器自己打分, 若反射器有系统偏差, 会被自己放大 (Constitutional AI 论文警告过).

策略 (实践中解决, 非研究级):

• 多反射器投票 / 周期性人工抽检 / 真实业务 KPI 兜底校验
• MetaEvaluator 定期评估 "评估器本身好不好"
• 关键决策保留人工审批 gate

---

11. 产品叙事修正

11.1 之前错在哪里

v0.1.0 CHANGELOG 过于技术化, 埋没差异化; 中间讨论也出现过度乐观叙事 ("OpenAI 做不了" / "护城河已完成"). 经 2026-04-19 战略校准后重写.

11.2 准确说法 (最终版)

Flyto evolve = 领域无关引擎 + 行业专属消费层 + ML 真实数据反射器 的飞轮. 垂直扩张路径: 飞驼云仓 → 仓储 → 物流 → 供应链, 参照 Salesforce/Palantir 玩法.

2025 两篇权威 survey 明确把我们的定位领域标注为未覆盖, 全球端到端产品化 0 家. 核心技术挑战 (credit assignment / 稳定性 / 冷启动) 是研究路线.

我们和大模型厂 (OpenAI/Anthropic) 叠加而非替代: 他们做全局反射 (全网 → 下一代模型 → 数月), 我们做本地反射 (本客户本仓 → 当前 Agent → 秒/天). 数据壁垒生效前 1-2 年先发优势窗口.

11.3 对客户话术 (TMS 场景)

云仓运营每天做的事 — 选承运商、设阈值、写补丁、跟异常 — 靠的是经验. 经验值钱, 但带不走、传不下去、新人要重学.

Flyto 云仓 Agent 是用你自己的真实业务数据训练的反射器. 它给你的建议不是 AI 凭感觉生成, 是从你过去几万单的真实结算结果里学出来的 — "Y 承运商在苏州线路旺季准时率 83%, 你上月已经被投诉过 3 次" 这种事实级反馈.

市面上的 AI Agent 大致三种: 一种只会写笔记帮你记录; 一种填模板给你三个 "可能的原因" 让你自己判断; 一种帮你执行但不学习, 下次同样问题还是得重新教. 它们都停在 "帮你省敲键盘的时间", 不触及 "让每次决策更准".

我们的 Agent 真的会变聪明, 因为它看过你所有历史数据的真实业务结果. 这不替代运营做决策, 是让运营的每个动作都基于事实而不是感觉.

11.4 对主管/销售话术

Flyto 走的是 "引擎 + 垂直行业" 飞轮路线. 引擎层做全领域通用能力, 上面叠云仓专属的 ML 反射器. 第一战飞驼云仓, 拿下后扩仓储 → 物流 → 供应链, 每个行业真实数据反哺引擎.

学术背书: 2025 两篇权威 survey (arXiv 2507.21046, arXiv 2508.07407) 把 "业务 KPI 闭环的系统级演化" 标注为未覆盖领域. 全球产品化 0 家.

竞争格局 (不点名, 按位置分类):

• 大模型厂: 做全局反射, 叠加不冲突, 商业模式决定不下垂直
• 编排框架厂: 只到多 Agent 协作层, 无业务反馈闭环, 无行业真实数据
• 国内大厂: 停在模型层和编排层, 组织固化不弯腰做垂直
• 垂直 SaaS 厂: 有数据无引擎, 产出专家系统不是自进化

我们的位置: 唯一同时具备引擎能力 + 垂直场景 + 真实数据反射器的组合.

时间窗口 1-2 年: 云仓第一战拿下后数据飞轮启动, 后来者补课成本快速升高. 这不是工期预测, 是数据壁垒生效前的先发优势窗口.

---

12. 实施路线图

12.1 原则

• 不按工期, 按 commit 数 / 代码面积 / 能力依赖链
• 引擎层不做数据接入 (见 project_architecture_decisions.md 数据接入边界), 只提供接口 + fixture 验证
• 行业专属 small model / 反射器训练由 platform 层或客户 负责
• 一次演化一维, 依赖前一维稳定

12.2 v0.1.x: 叙事修正 (不动代码)

• [ ] CHANGELOG v0.1.0 evolve 条目按 11.2 重写
• [ ] README 新增 "Evolve - 本地反射进化" 节, 引 arXiv 2507.21046 / 2508.07407
• [ ] core/pkg/evolve/doc.go 挂学术背书 + 承认 credit assignment 未解
• [x] memory project_evolve_rl_stance.md 已建 (2026-04-18)
• [x] project_strategy.md "领域无关 = 全领域" 校准已写入 (2026-04-18)
• [x] project_architecture_decisions.md 数据接入边界已写入 (2026-04-18)

12.3 v0.2: 引擎基建

• [ ] 反馈信号设计文档 feedback_signal_design.md (领域无关通用抽象)
• [ ] ParameterStore / ParameterEvolver 接口 + 文件系统实现
• [ ] 合规工具链 P1×7 (销售必答): SQL 只读校验 / Dry-run / 影子表 / 熔断器 / CAS / AuditSink DB / Staging 表
• [ ] Fixture 数据验证 pipeline (不接真实数据源)

12.4 v0.3: 反射器 MVP

• [ ] ML 反射器 training pipeline (接口 + fixture 验证)
• [ ] 第一维度: 承运商评分 (同路线 + 同季节 + 同承运商历史准时率)
• [ ] Shadow mode 灰度 (和规则并行)
• [ ] 合规审计接口 (评分依据的历史数据引用)
• [ ] 与 SkillLearner.RecordUsage 集成

12.5 v0.4: 局部 RL policy

• [ ] Policy network (选参数: 补丁阈值 / 异常触发阈值 / 审批层级)
• [ ] Contextual bandit 实现
• [ ] RLAIF/Constitutional 评分机制 (反射器自打分代替人类标注)
• [ ] Shadow → A/B → 生产三步灰度上线

12.6 v0.5: LogReplayer + LoRA 框架

• [x] LogReplayer 接口 + fixture (LogSource 接口, 不假设具体表) -- delivered 2026-04-18 (v0.2-dev, 提前于 v0.5)
• [ ] 离线扫描任务骨架
• [ ] LoRA 微调框架 (7-13B 开源模型, 引擎提供能力, 具体行业模型由 platform 套)
• [ ] M5 Max 128GB 本地调试 pipeline

12.7 v1.0: 引擎独立发布门槛

• [ ] Production stability: 稳定性 SLO 监控
• [ ] 演化透明度面板 (引擎侧 API, UI 由 platform 实现)
• [ ] 冻结模式 (客户可选关闭自动演化)
• [ ] 连续 N 次参数更新无漂移的稳定性验证

12.8 v1.5+: 垂直扩张 (不在引擎路线图)

以下属于 platform/ 子仓路线, 不在 core 引擎范围:

• 飞驼云仓 production ready 数据飞轮
• 扩仓储通用 (第二行业模板抽象)
• 扩物流全栈 (TMS/WMS/OMS 三域)
• 行业模型矩阵管理

12.9 v3.0+ 研究级

• [ ] Credit assignment 方案 (contextual bandit + shadow + hierarchical attribution)
• [ ] 冷启动 meta-learning (cross-customer parameter transfer)
• [ ] MetaEvaluator 实现 (评估器本身校准)
• [ ] 剩余参数维度覆盖 (Bundle 结构 / 缓存 / prompt 模板 / Agent 分工)

12.10 优先级判断 (当下最重要的 3 件)

1. 叙事修正 (v0.1.x) — 成本最低, 影响最大
2. 反馈信号设计文档 (v0.2) — 后续实现的前置, 不动代码
3. 合规工具链 P1×7 (v0.2) — 销售必答题, 无这些客户不敢买

以上完成后立即进入 v0.3 反射器 MVP.

---

13. 附录

13.1 PDF 章节映射 (TMS 动态承运商分配文档)

PDF 章节	内容	evolve Level
5.1-5.5 核心设计原则	单仓作用域 + 人工>规则>预测 + LLM 不做主决策	—
10 人工快速干预层	TTL 补丁生成 (自然语言→YAML)	1
12 包装知识解析器	三种状态 + 预测补全	2
14-15 承运商候选 + 结果预测	ML 预测器层	3 (参数可校准)
16 不确定性评估器	保守/审核/兜底决策	2
20 报价配置导入	文档解析 → DSL → 仿真 → 审批	1
23 目标可达性评估器	reachable/not 判断	2
24-26 配额/阶梯/均重池	数值状态引擎	3 (参数可校准)
27 经营先验注入	forecast_commitment_patch	1
28 有效边际成本	数值模型	3
29 决策公式	线性加权 FinalDecisionScore	3 (系数可校准)
30 滚动时域优化	未来 30 分钟 / 2000 单批	1-2
31-33 结算回放	对账 + 假设分析	长反射 backbone
35-36 大模型定位	用于 vs 不用于清单	验证 Level 拆分
40-42 监控指标	业务/报价/运行三套	Flyto Observer 接入点

13.2 学术论文清单

Must-read:

1. Comprehensive Survey of Self-Evolving AI Agents (arXiv 2508.07407)
2. Survey of Self-Evolving Agents (arXiv 2507.21046)
3. Maestro: Joint Graph & Config Optimization (arXiv 2509.04642) — 最接近 Flyto 定位
4. Evolving Excellence / Artemis (arXiv 2512.09108) — 唯一支持混合变量

Nice-to-read:

1. Trace: Next AutoDiff (NeurIPS 2024)
2. AgentEvolver (arXiv 2511.10395)
3. EvolveR (arXiv 2510.16079)
4. Awesome Self-Evolving Agents GitHub
5. DSPy Optimizers
6. Ensemble Active Learning Contextual Bandits Manufacturing (arXiv 2310.06306)

MLOps 现状:

1. Superwise MLOps Guide 2025
2. 2025 MLOps Landscape Uplatz
3. OpenAI Cookbook - Self-Evolving Agents Retraining
4. Galileo Human-in-the-Loop Oversight

13.3 相关 memory 条目

• project_agent_engine.md — 引擎项目状态
• project_strategy.md — 战略定位 (含 "领域无关 = 全领域" 校准)
• project_architecture_decisions.md — 架构决策 (含数据接入边界)
• project_evolve_rl_stance.md — evolve RL 立场 (2026-04-18 校准)
• project_agent_teams.md — Agent Teams 方向
• project_plugin_permissions_ui.md — plugin 权限 UI 北极星
• project_sandbox_local_vs_cloud.md — 本地 vs 云端沙盒
• project_tui_positioning.md — tui 定位
• project_version_roadmap.md — v0.1 vs v1.0 路线
• project_prompt_strategy.md — Prompt 策略

13.4 四方调研原始结论 (流水账归档)

Sonnet critic 五点反驳 (一级反向思考):

1. "OpenAI 做不了" 是时间点谬误
2. MLOps 工具链已做 5 年
3. N 维参数联合优化复杂度指数增长
4. B 端 TMS 反馈信号脏
5. 客户要可预期不要一切可变

MiniMax 中国视角: 国内大厂停在模型层和编排层, 大厂劣势是组织不是技术. 企业接受度高但要可控可解释. 致命盲点: 缺人机协同治理.

Agent A 全网学术+开源调研: 2025 两篇 survey 明确标注未覆盖. 学术底座 30-40% (Maestro/Artemis/Trace), 业务 KPI 闭环 0% 端到端. MLOps 只做 drift 重训 (推翻 Sonnet 第 2 点). 工业 TMS/WMS "adaptive neural models" 口号级, 公开披露空. 国内字节 AGILE / 阿里 AgentScope / 百度文心 / 腾讯元器都停在 "开发/编排/部署平台". Agent A 结论: 护城河不在能做, 而在 credit assignment 和稳定性悖论.

Haiku meta-critic (二级反向思考):

• ✅ MLOps 工具链论点被推翻 (Agent A 胜 Sonnet)
• ✅ 参数空间复杂度是真实障碍 (三方一致)
• ✅ 合规/可解释是销售现实 (三方一致)
• ❌ OpenAI 3 年内可做被推翻 (学术数据过去 3 年 0% 端到端)
• ⚠️ B 端反馈信号脏部分成立 (工程风险提醒)
• ❓ 冷启动 + 稳定性悖论具体方案未设计 (Flyto 自己要解决)

Haiku 综合判断: 护城河 60% 有条件成立. 业界唯一端到端闭环的产品级实现方向, 学术 0% + 商业 0% + 开源 0%.

13.5 竞品清单 (归档)

直接竞品 (Agent 自进化): Hermes (Nous Research 93k stars), Evolver/EvoMap (中国开源 MIT), Voyager (Minecraft 研究), AgentEvolver (arXiv 2511.10395), EvolveR (arXiv 2510.16079).

间接竞品 (技术底座): Maestro (arXiv 2509.04642), Artemis / Evolving Excellence (arXiv 2512.09108, TurinTech), Trace / OPTO (NeurIPS 2024 Microsoft), DSPy (Stanford).

MLOps 工具链: MLflow / Weights & Biases / Neptune / Superwise, Microsoft Contextual Bandit Decision Service, LangSmith.

工业 AI 产品 (口号级): Trimble AI-powered TMS, Pando Adaptive TMS, Intellitrans AI TMS, Imubit.

国内大厂/物流: 字节 AGILE, 阿里 AgentScope / 通义 / 扣子, 百度文心智能体平台, 腾讯元器 / 混元, 菜鸟天机π / 京东物流超脑 / 顺丰丰知, 华为盘古 / 智谱 / 第四范式 / 明略科技.

13.6 本文档关联 TODO 清单

合规工具链 (§10.3, §12.3 对应):

• [ ] P1: SQL 只读校验 / DB Dry-run / 影子表 / 熔断器 / CAS / AuditSink DB / Staging 表

evolve 新增 (§7, §12 对应):

• [ ] P2: core/docs/feedback_signal_design.md 设计文档
• [x] P2: core/pkg/evolve/parameter_evolver_default.go + ParameterStore + ParameterEvolver -- delivered 2026-04-18
• [x] P2: core/pkg/evolve/default_log_replayer.go + LogReplayer 接口 -- delivered 2026-04-18
• [ ] P3: ConvergenceValidator 实现
• [ ] P3: 稳定性 SLO 定义
• [ ] P3: 演化透明度面板 (引擎侧 API)
• [ ] P4 (研究): Credit assignment 方案
• [ ] P4 (研究): 冷启动 meta-learning
• [ ] P4 (研究): MetaEvaluator 实现

叙事修正 (§11 对应):

• [ ] P1: CHANGELOG v0.1.0 evolve 条目修正
• [ ] P1: README Evolve 章节补充学术背书
• [x] P1: core/pkg/evolve/doc.go 挂 arXiv 引用 -- delivered 2026-04-18

---

文档结语

本文档是 2026-04-18 战略讨论 + 2026-04-19 重大校准的整合版 (1242 → ~820 行). 详细讨论过程归附录, 正文只保留结论.

下一步: 接口讨论 → 接口实现 → 抽象设计回写本文档.

最后修改: 2026-04-19 作者: 飞驼产品经理 × Claude Opus 4.7