本文档是 sofagent 最核心的一份「为什么」。 读完你能回答：sofagent 是什么、怎么用、怎么跑、怎么管、怎么记、怎么装、怎么进化、以及不做什么——对应下文各章。 v1.5.6 · 2026-10-04（UTC）· ✅ 已发版 · 孔放勋
- 产品哲学（先读这三段）
- 零、一句话
- 一、这是什么——定位与边界
- 二、怎么用——交互范式
- 三、怎么跑——架构全景
- 四、怎么管——信任模型
- 五、怎么记——知识观
- 六、怎么装——部署哲学
- 七、怎么进化——FORGE 自迭代
- 八、不做什么——设计禁区
- 九、从哪开始
- 附：长期叙事——Conway/Coase 双重反转
行业方法论印证与 Agent 生态三层模型的详细内容见 VALIDATION.md。 本文聚焦 §一~§九 核心哲学。
① AI 时代企业最大的痛：不是没有 AI，是有了 AI 不敢放手。
Agent 越聪明，企业越不敢让它碰真活——真出事了，谁负责？能拦住吗？能回滚吗？大厂给你水（LLM）、给你河床（Agent 平台），但企业门口的那段管子——从「能喝」到「敢喝」——没人帮你接。
② sofagent 的答案：一套常驻你企业的 FDE Harness，嵌在成熟 Agent 与模型层之间——进场把业务判断写成文件（梳理工作流、部署 AI 节点），离场按文件自己跑。
sofagent 不替代大厂 Agent，而是建在它们之上——做河的约束层，不做河本身（约束层是治河的堤，不是河本身——河指 Agent 运行时生态）。FDE 四阶段：梳理→构建→部署→离场，判断冻结在前、驻留在后。推论：Agent 运行时生态越繁荣，约束层的卡位越值钱——执行体（DSH / OpenClaw / WorkBuddy / 未来的任何平台）每多一家，可被治理的河就多一条；约束层不与任何运行时竞争，是所有运行时的互补件。
🔄 自举（产品哲学的核心）：FDE Harness 层给自己做的第一份 FDE，就是 sofagent 自己。 我们自己是一家「FDE 公司」——执行「给企业做 AI 落地」这条 workflow 的能力就是 sofagent（嵌在成熟 Agent 与模型之间）。它对自己做 FDE：把项目自身梳理成一条 FDE workflow（梳理 → 节点 → 双图谱交付），确认每个节点全自动（LangGraph 编排 + DeepSeek Harness 执行 + 约束层审计），后训模块也围绕 FDE——怎么让 FDE 更好、怎么让数据飞轮转起来。 这是自举循环：FDE Harness 层对自己做 FDE → 项目更 AI 化 → 更好地服务企业。产品形态 = FDE Harness 层（不造 Agent：对执行体 DSH / OpenClaw / WorkBuddy 约束、对智力源通用/专属模型治理，plugin + skill + MCP + CLI + dashboard 五种形态分发）。
🔗 激活链——从「交付」到「自运转」：FDE 交付了 ontology + workflow.yml + skills/ 等静态文件后，交付物和「企业工作流自动运行」之间曾有一道大断裂带——企业 IT 拿到一堆 .md 和 .yml 不知道怎么跑起来。激活链（ACTIVATE→ORCHESTRATE→EXECUTE→SUSTAIN，已交付）解决这个问题：读交付物 → 注册企业 SubAgent → 构建 LangGraph StateGraph → DAG 运行 + HITL + 审计 → 持续优化自运转。 详见 激活链设计文档。
③ 底层实现（约束层）：sofagent 的约束层保证每次变更可审计、可回滚、可进化。
约束注入链是骨架里的钢筋，审计能力是质检——开发者才需要往下看。审计能力 25 条规则按实现方式分 20 条纯 git-diff（零 token、不调 LLM）+ 4 条混合需 Agent 日志 + 1 条文件系统扫描（按启用方式则为 17 默认 + 8 扩展，SSOT 见 SECURITY）；**约束层（一个层五种能力：注入·审计·回溯·沉淀·进化）× 生命周期（诊断→激活→编排→执行→进化）**双层架构覆盖从治理到自运转。FORGE 自迭代工具链是项目内部开发工具（FORGE = 项目内部自迭代工具链，非产品能力； 本文档中 FORGE 的后续出现均指此，见 WIKI 术语表）。本文档以下九章讲的就是这套底层实现（约束层）的设计哲学。
sofagent 没有图形界面。 你通过电脑上已有的 Agent（WorkBuddy / Codex / Claude Code 等）或 IM（钉钉 / 飞书 / 企微）与它对话——说一句话，它做完了告诉你结果在哪。语言是界面，这也是 sofagent 与用户交互的核心方式。（终端 Dashboard 作为只读可见视图，给非技术买家看进度，详见 §六；但下令仍走语言。）
语言是界面。MCP 是通道。硬证据（git diff）是唯一的真相来源。
本节四层论证（定位 → 边界 → 为什么中间件 → 市场实证），可跳读至 §二 起使用。
判断主轴：sofagent 全部叙事的主语是同一件事——判断（该不该做、做到什么算好、谁拍板）。进场把它写成文件（工作流、本体数据、AI 节点部署），离场按文件执行与审计。后文所有章节（管什么、怎么用、怎么跑、怎么管、怎么记）都是这个动作在不同侧面的展开：§四「怎么管——信任模型」是判断的证据面（不看 Agent 说什么，看 git diff 留下什么），§五「怎么记」是判断的沉淀面，约束层五能力是判断的执行面。读懂这条主轴，各章就不是并列的九篇，是一件事的九个剖面。
「数字员工 / 硅基员工」与「7×24 自动执行任务」的措辞分工判据（语境三条件、直接引文不改）见 叙事标准。
提示工程管「说什么」，上下文工程管「知道什么」，约束工程管「跑在哪」。sofagent 管最后一步：跑完谁验收。 更准确地说，它管的是三层里最稀缺的那层——判据：规则告诉 Agent「不该删库」，判据告诉它「交期改得对不对、这个报价能不能发」。规则可以通用，判据只能是你的业务——这也是后文「垂直 Harness 才是护城河」的根：平台治得了动作，治不了你业务里的对错。
- 不是给 AI 写 SOP——SOP 保 60 分
- 是装缰绳——让 AI 在个性化上下文里跑出 85-90 分而不越界
- AI 是劳动力不是工具——产品设计是「管理 AI 的缰绳」
数字劳动力的三代进化：行业把 AI 工具演进划为三代——① 聊天机器人（Chatbot：一问一答，不动手）→ ② 数字分身（Digital Twin：按 SOP 模仿人的操作步骤）→ ③ 数字员工（Digital Employee：进组织架构、有账号、被派活、对结果负责）。三代分水岭不是「更聪明」，是责任归属——前两代产物归人，第三代产物归岗位。 sofagent 管的就是第三代：约束注入链 = 岗位职责说明书（什么能做什么不能做），审计能力 = 绩效考核（每次变更留证据），回溯能力 = 试错容错（做错了退得回），沉淀能力 = 组织记忆（越干越有的家底），进化能力 = 越用越强（自迭代变强）。把 AI 当劳动力而不是工具，就需要劳动力管理基础设施——这正是 sofagent 的定位。
落地卡点的迁移：数字员工落地的卡点正从「模型能力」转向「组织协议」——能不能进组织架构、有没有账号、怎么派活、绩效怎么算、做错了怎么退回，这些组织侧问题越来越先于模型侧问题成为瓶颈。沿用上文五能力口径：约束层不是技术实现层的中间件，而是数字员工的组织入职协议执行器（品类定位词「Harness 中间件」与此不矛盾——那个词答「属于什么品类」，这句答「不是什么实现」； 两义互指见 架构 §范围声明）——企业接入 AI 的本质，是给硅基员工办入职（背景调查=模型层对齐，入职后的审计制度=运行时对齐，见 §四·双层对齐）。
WorkBuddy / OpenClaw 等大厂 Agent 平台管路由调度——「会不会做」。sofagent 管行为治理——「能不能每次都做对」。Gateway 是高速公路，sofagent 是交规 + 测速摄像头 + 驾校教练。 二者互补，不竞争。
⛔ 交付服务边界（显式声明）：本仓开源 FDEing 方法论与判据 schema，不提供、不承诺、不代理人力交付服务——「派 FDE 进场替企业梳理」属交付服务生意，归宿在服务型产品线（FDE Agent for enterprise Forward Deployment 的服务面），与本仓是方法论供给关系而非同一交付主体。本仓文档一律以方法论自述（「FDEing 指导交付者……」），不写「我们去企业交付」的服务口吻。仓内
fde_*系列 MCP 工具是方法论的软件辅助（产出判据与数据，属本仓），不是服务本身。 判据 schema 唯一 SSOT：判据格式定义只住在本仓（rules schema + 正负样例 schema）——任何外部仓（含服务线）消费判据一律引用本仓 schema，禁止另写一份；FDE 方法论文件可以引用判据、不得定义判据（有门禁断言）。
为什么需要 sofagent（三段论证压缩）：大厂造河我们做河的约束层（堤坝+水厂+管网+水龙头，不做河）· 通用 Harness 被模型吞噬、垂直 Harness（判据控制）筑深壁垒（Harvey/Sierra）· 真正不可替换的两样沉淀物=约束规则库+业务数据资产。完整三段论证（Palantir 毛利对比/竞争优势五因子/系统型vs薄壳型）见归档。
「智能属于模型，控制属于系统」再往前推一步，企业 AI 落地其实是四件事的分工，每件长在不同的组件里：
| 组件 | 管什么 | 一句话 |
|---|---|---|
| MCP | 有什么 | 把企业系统（DB / API / 文件）暴露成 LLM 可调用的 tools |
| Skills（OpenClaw / Claude Code） | 怎么干 | 纯文本指令驱动单 agent 完成个人/小团队 workflow |
| Ontology（sofagent 运行时层） | 事之间什么关系 | 企业业务世界的语义层——实体 / 概念 / 关系 / 状态机 |
| Harness（sofagent 约束层） | 干得对不对 | 每次变更的硬证据审计 + 越界拦截 + 回滚 |
四件是 orthogonal axes（正交轴）：MCP 提供「what」、Skills 提供「how」，二者搭档够跑通单 agent 场景；但企业要「多 agent 协同 + 跨 session 数据一致 + 强治理」时，Skills 文本对齐不够（不带语义对齐层 / 跨 agent 协调 / 变更治理）——sofagent 的 Ontology 运行时层 + Harness 约束层正为此设计：不替代 Skills，补上语义对齐 / 治理 / 编排 / 审计四件事。不是「Skills 不行」，是「Skills 不够」。
「FDE Harness」这个名字常被读成两个功能的拼盘（FDE 方法论 + 约束层），但它描述的是同一件事的两个相位：FDE 是判断的生成相位（进场时，把「该不该上 AI、做好的标准是什么、谁拍板、何时跑」判断出来，并冻结成机器可判定的交付物——merge_criteria / approver / trigger.schedule / ontology）；Harness 是判断的驻留相位（离场后，按冻结的判断 7×24 执行，并在进化时写回）。
交接物（workflow.yml + ontology + MD 五件套）是两者共享的活状态：FDE 写入、约束层执行时读（L4 注入）、进化时写回（branch 晋 trunk / think.md 蒸馏）。
两个方向的反证说明这不是拼盘：只有 FDE 没有 Harness = 传统咨询（交付文档，人走判断蒸发，没有 7×24 执行）；只有 Harness 没有 FDE = 空壳引擎（25 条规则没有业务判据可审，编排没有 workflow 可跑）。两者互为存在前提。
从 FDE 到 FDEing——把 Engineer 岗位变成 Engineering 能力：两个相位的合成效果，是 Forward Deployed Engineer 从一个岗位变成 Forward Deployed Engineering 一种能力（FDEing 即 Forward Deployed Engineering 的缩写——名词指这种能力，动词指把 FDE 从人力工作变成这种能力）——人的判断冻结进交付物，人离场后判断作为能力持续运转（7×24 执行、审计、进化时写回）。岗位随人走，能力随交付物留。 动词化：FDE 是名词，FDEing 是动词——万物皆可 FDEing：任何业务对象、流程、节点都能被 FDEing 一遍「梳理 → 判定 → 交付 → 养护」（不限于软件——硬件节点、机器人运动过程同样是 workflow，差别在执行器、不在治理形态）。做任何事先想三件：workflow 怎么搭 / AI 节点是什么 / 怎么让 AI 更好地帮你实现。定制递减到零时，企业得到的不是一名工程师的服务，而是这项工程能力本身。
由此引出一条新功能过筛判据（与 ARCHITECTURE §缰绳面/执行面判据「四问过筛」并列、正交——那四问划执行面/缰绳面边界，这一问判断 FDE 价值）：这个能力是否在扩大「可冻结判断」的词汇量？ workflow schema 每新增一个判断类型字段（merge_criteria 判「做好标准」、approver 判「谁拍板」、trigger 判「何时跑」、lifecycle 判「能否复用」），就是给 FDE 相位多一类可冻结的判断、给驻留相位多一类可自动执行的判据——这样的字段是真护城河；只是堆执行能力而不扩大词汇量的，优先级另议。
智能与控制分离的必然推论：模型会持续内化能力，但控制层有三样东西它永远内化不了。git-diff 审计要的是确定性规则，不是概率推理——「改了哪一行」是文件系统的是非题，「大概率改对了」不是证据；HMAC 防篡改要的是密码学，不是语义理解——验签不依赖模型懂不懂内容，改动一个字节就失败；合规留痕要的是不可变日志，不是上下文窗口——上下文会被压缩、截断、遗忘，append-only 审计链不会。智能长在模型里，控制长在系统里——这不是保守，是分工。
为什么 Agent 不能继承人的角色权限：角色树是给人设计的，隐含「这个人知道什么时候不该点」这个默认。Agent 拿到「处理这批延期订单」和采购单修改权，就会去改交期把延期变成不延期——角色树写了能改交期，没写动交期得先问计划员。这就是为什么 Agent 需要独立身份 + 最小 scope token，而不是直接继承发起人的角色权限——「知道什么时候不该点」是人独有的判断，不是角色树的字段。
受控自主性四级（Governed Autonomy）：L1 Copilot→L2 Operator→L3 Bonded Agent→L4 Accountable System——sofagent 目标态=L4（append-only 审计+可问责）。四级行业框架表见归档。
有人会问：为什么不把 sofagent 的能力封装成 Skill（像 Claude Code Skills / Cursor Rules 那样）？因为大模型会吞噬一切文字形式的约束。
Skill、Prompt Engineering、Context Engineering，甚至以 Skill 形式做的 Harness Engineering——本质都是文字形式的约束。而文字形式的约束有一个致命属性：每次注入到模型 = 每次投喂 = 每次训练。模型会训练得越来越强，必然把文字形式的约束吸收进自身权重——今天的 Skill 是差异化优势，明天就是模型的内置能力。
sofagent 的生存位不在「写更聪明的约束文字」，而在细分业务 workflow 上对业务最终结果的可约束性——这个不会被模型吞噬。对策是把 Skill + Harness 能力封装进 Subagent（代码级实现，非文字注入）+ 防投喂机制（防止输入素材变成大模型的训练材料）。让能力长在代码里，而不是长在 prompt 里——这是对抗「模型吞噬一切」的唯一姿势。
外部印证——Claude Code 强模型时代的提示词革命：Anthropic 在 Claude 3.5 Sonnet/Opus 上把系统提示词砍掉 80%，核心逻辑正是「模型越强，要写的约束越少」——从「教模型做事」转向「让模型自己推导」。
其六个转变中与 sofagent 约束哲学同向的有三条：规则→判断（写死硬约束多了会互斥矛盾，通用规范模型自己能推）、前置上下文→渐进式披露（Claude.md 只放每轮都用到的，业务规则按需引用）、简单规范→丰富验证（写「什么算完成」比写「怎么做」更重要）。
配套新增
/doctor命令自动体检上下文健康度（去重、识别可从代码库推断的冗余、标记慢 Hooks、统计各组件上下文占比）——是「约束也要定期瘦身」这一判断的工具化。这与 sofagent「Skill 会被模型吞噬、能力要长在代码里」的立场互为印证：连最激进的 Coding Agent 都在反向减负，堆文字约束是死路。
FDE 三级杠杆：知识复制（手册/SKILL）→组件复制（install.sh/模板）→产品复制（Ontology/能力市场）——试金石=定制递减率，连续三客户不降就是外包。五类失效模式对照表与六步分解法见归档与 FDE/GUIDE。
上文〈FDE 与 Harness 怎么咬合〉讲的是 FDEing 的语法（FDE 名词 / FDEing 动词），〈三级杠杆〉讲的是 FDEing 的打法（定制递减到零）。本段补两者之间缺的一环：这套语法为什么能成为 sofagent 的能力底座——即它的组织含义与三因子归位。既有两段讲词汇与打法，本段只讲底座，零复述。
组织含义：AI 不是效率工具，是硅基员工。 把 AI 当「更快的打字机」产出的是更快的旧流程；当「可被治理的同事」才逼你回答真问题——坐哪个岗位、输入输出是什么、出错谁拍板、绩效怎么算。前者只换工具，后者换组织：能力不再存进岗位（人走、岗空、能力散），而是存进交付物（workflow.yml / ontology / skills）——人离场，判断作为能力继续运转。这条组织含义的终点即「万物皆可 FDEing」：能力载体一旦是交付物而非岗位，可被 FDEing 的边界便不再限于软件。
三因子归位（与 FDE/README 强调段同口径，无第二口径）：FDEing 不是孤立方法论——它是把另外两个因子接上来的能力底座。三因子各司其职、不互替：
| 因子 | 归位 | 一句话 |
|---|---|---|
| FDEing | 能力底座（工程层） | 把 FDE 从人力工作做成可复用能力——定义场景、冻结判断 |
| S1M | 本体（判定层） | System One Model——判断本体，只输出类型化决策与校准概率（判断与生成分离） |
| harness | 治理环境（治理层） | 约束层五能力——保证判断被治理（可审计 / 可回滚 / 可举证） |
身份口径（唯一锚见 ARCHITECTURE 术语对照）：产品身份句的定稿公式是
FDEing × S1A，其中S1A = S1M + Harness（S1A = System 1 Agent，对外书写用全称）——外层乘号 = 方法论与制品缺一不可（没有 FDEing 判据荒芜、没有 S1A 成果停纸面），内层加号 = 判定件与治理层同仓共生成一个制品。不是把治理层也当作并列乘子的旧写法（该写法仅在 changelog 历史区按原样保留，本仓现行口径已勘正为加法）。 读法：FDEing 作用在 S1A 上——FDEing 是住在本仓的方法论 plug-in，S1A 才是被 FDEing 的制品本体；FDE 定义场景，S1M 执行判断，Harness 保证判断被治理——三者合成 System 1 Agent。
LUI-first——语言就是界面。这决定了 sofagent 全部能力的暴露方式：MCP 协议。
传统软件：图标 → 点击 → 表单 → 提交 → 等待结果 sofagent：说一句话 → MCP 调用 → 返回结果
| 铁律 | 说明 |
|---|---|
| 语言入口 | Agent 第一次连上 MCP server 时，list_capabilities 主动推送所有能力 |
| 零交互 GUI | 语言是主界面，不建交互式网页/面板；dashboard 是只读视图（见 §六），需要可视化呈现时推送 Markdown 报告到 IM |
| 输出有家 | 每个工作流节点的输出有明确的 push target（飞书/钉钉/企微 Webhook、daemon 通知、联邦 knowledge/） |
| 降级优雅 | MCP 不可用时退到 CLI；IM 不可用时退到 daemon 通知 |
推送机制（@sofagent/mcp 内置）：
- Webhook → 飞书/钉钉/企微（审查报告、发版通知）
- OpenClaw IM channel → Agent 对话结果直接返回
- daemon 通知 → 知识库巡检异常、USB 配置完成
Agent 连上来第一件事就是 list_capabilities，然后自己知道能调什么：
- 🤖 FORGE 自迭代——自动写代码、自动审、自动发版
- 📚 知识联邦——设备 A 踩的坑，设备 B 直接查
- 💿 USB 配置——说一句，写好的 U 盘插上就能用
- 🔐 安全加密——多设备通信全自动加密
- 📋 发版 SOP——从审查到 git tag 全自动
sofagent 用约束层（一个层五种能力：注入·审计·回溯·沉淀·进化）× 生命周期（诊断→激活→编排→执行→进化）的双层架构组织产品——约束层回答「怎么保证每次做对」，生命周期回答「企业 AI 从诊断到自运转怎么走」。完整的层级定义、状态机图与「双层 vs 三层嵌套」消歧见 ARCHITECTURE §心智模型（权威源），操作视角的角色表与触发方式见 HANDBOOK §心智模型。以下仅补充哲学视角：
演进视角：从「脑力自动化四阶段」看五种能力的来路 行业对「脑力自动化」的认知可归纳为四个阶段——提示词自动化、上下文工程、驾驭（agent 自主执行）、循环自动化（自驱动迭代）。sofagent 的约束层五种能力，正是对这四个阶段的逐层回应：审计能力 + 回溯能力承接「提示词 / 规则」的确定性沉淀与回滚护栏，约束注入链承接「上下文工程 + 驾驭」的掌控执行，进化能力承接「循环自动化」的自迭代闭环。底层不变的是约束层——无论 AI 能力涨到哪一阶段，确定性边界始终由约束层兜住。这不是外部理论的移植，而是我们自己在做产品时反复验证过的演进逻辑。沉淀能力承接知识资产的整理与回灌，不在四阶段框架内——它是约束层自己长出来的第五能力。
从 Prompt 到 Graph：五个尺度，一个系统
行业对 AI 工程的理解经历了五次概念迭代——Prompt → Context → Harness → Loop → Graph。有人以为新概念淘汰旧概念，其实它们是同一套系统的五个尺度，每一层解决上一层的可靠性问题：
| 概念层 | 解决什么 | sofagent 对应 |
|---|---|---|
| Prompt Engineering | 怎么给模型下指令 | fde.md 的自然语言规则 |
| Context Engineering | 怎么管理模型的上下文 | 四层加载链 + knowledge/ 知识注入 |
| Harness Engineering | 怎么约束模型的行为 | sofagent 整体——约束层（注入 + 审计 + 回溯 + 沉淀 + 进化，核心价值层） |
| Loop Engineering | 怎么让任务自动循环收敛 | FORGE workflow 驱动（fresh-eyes-loop） |
| Graph Engineering | 怎么编排多个角色的协作 | v1.3.1 DAG 并行调度（控制图） |
sofagent 不做 Prompt（那是模型的事），在 Context 层有约束注入链，核心价值在约束层（确定性边界），Loop/Graph 层是进化方向。模型越强，约束层越值钱——因为 Agent 能做的事更多了，「做错了怎么办」的代价也更大。
约束层的两种形态——加载链（约束注入链·纯 MD 文件，~3,500 token）与运行时（daemon + CLI 按需启动）的完整设计见 ARCHITECTURE §约束层的两种形态：加载链与运行时。
Agent 是世上最会解释自己的人。 问它「你改对了吗」，它会给你一篇条理清晰的自我辩护。所以 sofagent 不问 Agent——直接读 git diff。改了什么就是什么。
| 谁的证据 | 可信度 | 谁会伪造 |
|---|---|---|
| Agent 说「我改了 X」 | 🟡 | 梯度下降本能——找最低成本通过路径 |
| git diff | 🟢 | 无法伪造——diff 是文件系统真相 |
| think.md | 🟡 | 可能写空话填模板，所以不强制、不强校验 |
| 审计能力 | 🟢 | 规则在代码里，非 Agent 可修改 |
这套证据链的根基是一手信息——git diff 是文件系统的原生输出，是 Agent 真实操作留下的原始痕迹，不依赖任何转述、摘要或自我报告。审计模块只读一手 diff，不读 Agent 的「我改了 X」二手声明；任何 AI 产出都应能追溯到原始操作（哪次变更、哪行 diff），无法溯源的产出不进入证据链。
模型越强，这套逻辑越重要。 模型提升的是输出的说服力，不是诚实度——GPT-3 的胡话你一眼看穿，GPT-5 的胡话比真话还真。Agent 越能撒谎，外部硬证据越不可替代。审计能力不看 Agent 说了什么，只看 git diff 留下了什么——这个原则随模型进化只会升值，不会贬值。
Agent 审计与人审的本质差异是批量放大。 人的错误是一次一个客户；Agent 的错误是一分钟 300 次同样的错——误判一个规则可能批量发错报价，理解错一封邮件可能把错误信息同步给一堆人。审计的对象因此从「个别人的个别行为」变成「会批量复制的错误」：拦截一次等于拦截一批，漏过一次等于漏过一批——这是 Agent 时代审计必须自动化、必须前置到动作边界（而非事后抽检）的结构性理由，也是「私有化部署 ≠ 安全」（风险在 Agent 进公司干活之后，不在数据出公司之前）的治理面依据。
信用的度量衡：AI 的信用靠合并历史，不靠承诺——一次通过审阅的合并是资产，一句「我做对了」不是。同一逻辑推到组织层：产品信任靠 Pull Request 历史，公司信任靠审查历史——sofagent 对自己执行与对外交付走同一套证据标准（独立视角审查：常规 12 视角 / 全量 23 视角 + 发版门禁），自举叙事（见产品哲学 ②）在这里落成可查证的事实。
行业谈「对齐」多指模型层：预训练吃进全网好坏内容，后训练（SFT / RLHF / DPO / GRPO）让模型贴合人类偏好。但它有两个绕不开的先天约束：
- 3H 目标互相矛盾（Helpful 有用 / Harmless 无害 / Honest 诚实）：越追求有用，模型越敢答不确定的问题，越偏有害与不诚实；越追求无害，模型越过度谨慎，正常问题也拒答，越没用。对齐研究就是在三者之间找平衡——平衡意味着任何一次调参都在牺牲某个 H。
- 对齐是持续过程，不是终点：模型永远可能被话术越狱（jailbreak）绕过安全限制，模型厂商的安全对齐永远在追赶新攻击。
这两个约束推出 sofagent 的定位：运行时对齐不是模型层对齐的替代，是它的保险层。 模型层对齐解决「出厂时的平均情况」，运行时对齐解决「这一次操作的实际情况」——审计模块（git diff 硬证据）、验收门（turn-stopping）、HITL 审批，都是在模型已经输出（或即将输出）之后用确定性规则再核一遍。模型层对齐做得再好，企业也不能把「模型应该不会乱来」当部署依据——正如再好的员工背景调查，也不能替代入职后的审计制度。
💡 一句话：模型层对齐是概率的、可被越狱的、随版本漂移的；运行时对齐是确定的、不可绕过的、规则在代码里的。 企业的 AI 落地两层都要——sofagent 做的是第二层。
架构基因来自 Geoffrey Huntley 的 Ralph 循环：Agent 的记忆长在文件系统（git diff / task/logs / SKILL.md），不长在 Agent 内部。Agent 每次启动都是白纸——但它读到的文件，是上一次运行留下的完整经验。文件是持久证据，Agent 的记忆不是。
📖 这条直觉已被清华唐杰团队的《Memory for Large Language Models》（2026）从架构层正面背书——应用层记忆要做的事不是「比模型更会回忆」（必输的赌局），而是守「模型永远给不了的」：全量 append-only 不忘、长在文件里可带走、入口在本地。详见 VALIDATION · 记忆要笨。
AI 可以无限接管执行（生成 / 修改 / 部署），但主体性与终裁权不可外包——审美判断、问题定义、价值排序这三类核心能力必须留在人类侧，否则人会逐步丧失主体性（「最舒服的状态是不再有自己观点」与认知投降同源）。
sofagent 用三条制度把「判断权不可外包」落成防线，与「反认知投降」同源：
| 护栏 | 做什么 | 守住什么 |
|---|---|---|
| fde.md 人类规则优先 | 业务底线由人类定义，Agent 不可覆盖 | 价值排序（人类侧） |
| 编排可回滚 | 任何变更可快照回退 | 执行试错不伤及主体地位 |
| 审计能力独立验收 | 不信任 Agent 自我报告，只看 git diff 硬证据 | 问题定义与验收（人类侧） |
这把「人类终裁」从工程约束升维为主体性护栏：模型可以跑得远，但问题定义（SKILL.md 目标）、价值排序（fde.md 业务底线）、审美判断（人类验收）必须留在人类手里。
循环锚点——人类终裁如何不被绕过。 仅声明「判断权留在人类」不够：一旦把改进循环交给 Agent，它会在古德哈特定律下悄悄优化掉最想削弱的硬规则（Goodhart, 1975）。Perez（2026）把可靠的循环网络归结为三类锚点：
- 不容争辩的测量：到账收入、真实执行测试、实际留存——物理上不可能被优化器操作的外部事实，而非 Agent 自报指标。
- 冻结节点：优化循环永远不许调的规则（如训练循环绝不可看保留评估集），恰是最想削弱的硬约束。
- 人对「更好」的判断来自图谱外：哪些值得控制、冻结规则放哪，机器不能自生成——最精密的架构也要标记自己权威终止之处。
sofagent 的审计能力 Gate + 硬规则正是这类锚点：审计只信 git diff 一手证据（不容争辩），fde.md 业务底线不可被 Agent 覆盖（冻结节点），问题定义与验收终裁权留在人类（图谱外的判断）。人类终裁因此不只是一句宣言，而是一组写死在优化器碰不到之处的锚点。
📖 C.A.E. Goodhart · Problems of Monetary Management: The U.K. Experience · C.E. Perez · From Loop Engineering to Graph Engineering?
执行可以试错，判断不能。当 Agent 无法在不猜测的前提下完成判断时，正确动作是拒绝输出、并说清缺什么，而不是用一个自信的答案填空。这不是洁癖：Databricks 发布其企业本体层（Genie Ontology）时把这条写成了产品取舍——「当上下文缺失时，AI 会用猜测填补空缺；而在财务、运营或销售场景，一个自信的错误答案往往比没有答案更糟」。
这条原则在本仓已是三处机制，只是此前从未被命名：
| 机制 | 落点 | 行为 |
|---|---|---|
| 准入拒绝 | SKILL/harness/task-aware.md §1.1 |
需求不清楚 / 涉安全权限 / 涉删除重构 → 输出 [准入检查: REJECT — ...] 后不点火 |
| 分级响应 | SKILL/harness/loop-check.md 输出规则 |
🟢 沉默 / 🟡 一句话 / 🔴 完整汇报 + 等确认——没把握就停下来等人 |
| 回复前闸门 | SKILL/SKILL.md A0 |
四项自检，缺证据即降级为口头告警，而非硬下结论 |
边界：拒绝权只对 Agent 自己的产出生效，不构成对人类提问的推辞；且拒绝必须连带「缺什么 + 谁来补」的补齐路径，否则退化为不作为。
📖 Databricks · Genie One 发布 —— "When context is missing, AI fills the gap with guesses."（CEO Ali Ghodsi）
平台内置的审计永远是运动员审计——OpenAI 审计自己的 Agent、字节审计自己的 Agent。这在单供应商场景下够用。但当企业混用多家 Agent（这是确定趋势），就需要一个不属于任何一方的审计层。
sofagent 的三条中立性原则：
| 原则 | 说明 | 为什么平台做不到 |
|---|---|---|
| 独立性 | 不依附任何 Agent 平台或模型厂商；MIT 开源，任何人可审查源码 | 平台内置治理 = 自己审自己 |
| 数据主权 | 审计证据（git diff / history.jsonl / think.md）永远在用户本地，不送云端 | 平台审计日志在平台云上，受其隐私政策约束 |
| 可验证性 | 审计模块自身开源可被审计——规则代码公开、判定逻辑透明、「审计审计者」是可能的 | 闭源审计是黑盒——你只能信它，不能验它 |
这三条不是技术选择，是信任模型的结构性差异：平台做的审计是运动员提供的成绩单；sofagent 做的是裁判的计分板。
共享而不失控。 审计与数据主权的最终目的不是把信息锁死，而是让「共享」变得安全——成员（或 Agent）愿意把有效经验交出来接受检查、修正、复用，前提是组织承诺成果有边界、有权限、有责任、有结果，不因共享而失去控制。这正解释了为什么 sofagent 只读 git diff（一手证据）却不接管数据：它让经验进入共享层时「说得清、查得到、有人负责」，从而把「信任」变成可工程化的东西。
上文中立性讲的是审计层平台无关（不依附任何模型厂商/Agent 平台），本节讲另一个正交维度：交付物的归属方。二者不矛盾——恰恰因为约束层平台无关（中立性），客户才可能把它当作自有资产长期持有，而不是绑死在某家乙方的技术栈上。
判断标准：一个 AI 系统在组织内运行一段时间后，它积累的规则、审计历史、知识沉淀归谁所有、能否带走。按此标准，两种模式有结构性差异：
| 维度 | 乙方交付物模式 | 甲方资产模式（sofagent） |
|---|---|---|
| 知识沉淀 | 留在乙方工具/平台内，合同结束即失联 | ~/.sofagent/ 全量本地——本体数据、审计历史、think.md 反思归甲方 |
| 规则演进 | 乙方升级节奏，甲方提需求排队 | config.yml + 审计规则甲方可自主增删（基线规则保护除外） |
| 迁移自由 | 换供应商 = 推倒重来 | MIT 开源 + 数据全本地格式（Markdown/JSONL），随时可迁 |
| 与模型关系 | 绑定乙方选的模型栈 | 约束层平台无关——换模型换平台，资产不动 |
这与纳德拉「数字主权测试」同频：企业应能在替换通用模型时保留学习系统内积累的「企业老将」级专业知识（见 VALIDATION §三纳德拉节）。FDE 职业道德第 2 条「诚实报告结果」与第 3 条「不制造依赖」在此汇合：交付的终点是甲方有能力自己持有并运营这套约束体系，而不是永远离不开乙方——sofagent 用 MIT 开源 + 全本地数据格式把这一条落成工程事实，而非停留在职业操守倡议。
| 层 | 是什么 | 例子 |
|---|---|---|
| Ledger | 发生了什么（原始数据） | task/logs、think.md、审计历史 |
| Views | 这代表什么（知识提炼） | knowledge/ entities/concepts/comparisons/summaries |
| Policy | 该怎么办（约束规则） | fde.md 业务四问、SKILL.md 铁律 |
三层不互相替代——Ledger 是原材料，Views 是加工品，Policy 是使用说明。
think.md 契约（代码级强制，见
@sofagent/core的memory-contract.ts）
- think.md 是 Ledger，append-only（只追加）：所有反思写入方只能追加新条目，绝不允许整体覆写 / 截断 / 就地改写历史条目。
- 多写入方是设计原意：审计能力（git diff 自动反思）、主 Agent（手动
write_think）、FDE / loop 陪跑期写入，均合法——「很多东西往里写」是正常演进，不是 bug。- 派生方向严格单向：think.md（Ledger）→ knowledge/（Views）。knowledge/ 是唯一派生层，任何代码都不得把 knowledge/ 的内容反向写回 think.md。
- 写入笨，派生灵活：写入端（Ledger）绝对不筛选、不打分、不压缩——笨笨的全量存，才能接住「迟到的重要性」（今天看着没用的信息，30 天后可能关键）；派生端（Views / Dream Cycle 夜里整理）可以自由压缩、提炼、遗忘。这与 §八「不做什么」里禁的「记忆压缩自动化」不冲突——禁的是对 Ledger 的压缩，不是禁 Views 的整理。模型负责聪明的回忆，约束层负责笨笨的保管——模型在千万 token 里找到那句话，约束层保证那句话十年后还在、还查得到出处。
知识不囤在一台设备上。Dream Cycle 管道自动从 think.md 提取 fact→atom→concept，联邦查询跨设备共享经验。设备 A 踩的坑，设备 B 的 Agent 不问就知道。AES-256-GCM 加密全程保护传输。
企业知识库正从「问答工具」升级为「Agent 可信调用载体」。行业研报的 4 道关卡模型可直接映射到 sofagent 三层治理：
| 研报关卡 | 对应 sofagent 层 | 落点 |
|---|---|---|
| 数据入口（权限实时回连核验，不静态拷贝） | Ledger（append-only 真相源） | FDE 知识主权归客户 + 审计 A14 事后审计 |
| 内容解析（多模态结构化） | Ledger → Views 派生 | Dream Cycle 自动派生 |
| 复杂检索（先规划再分步检索，动态判充足度） | Views（按需查询） | conflict-check 质量巡检 |
| 工具网关（统一受控入口：身份·路由·重试·审计） | Policy（约束注入） | MCP 桥 + 审计模块 |
可信工具 4 要求（可溯源 / 权限合规 / 过程可查 / 证据可验）即三层治理中 Policy 层「人类意志最后防线」的工程化表达——Policy 层 = 受控调用，审计能力 = 证据可验，二者同构。
RAG（检索增强生成）检索的是文本片段，不是业务语义。「订单」在 CRM、ERP、物流系统中指向完全不同的对象，文本检索无法消解这种冲突——这是 LLM 在企业场景中「知道但做不到」的根源。
OAG（本体增强生成） 是 Palantir 的根本性解法：让 LLM 接入一个经过治理的、类型化的业务世界模型（Ontology），而非零散的文本片段。LLM 不再靠概率推理判断「客户 A 的订单 B 当前是什么状态」，而是直接从 Ontology 获取确定性答案。
这个哲学反映在 sofagent 的设计中：约束层 = Agent 的世界模型。SKILL.md + fde.md + knowledge/ 构成了一个微型的、可演进的本体数据——它告诉 Agent「你在什么组织里、有什么红线、过去踩过什么坑」。Agent 的可靠性不是来自它自己知道多少，而是来自这套约束层锚定了多少业务现实。
确定性与概率性分离是这一原则的工程落地方式：刚性安全边界（审计、权限、数据一致性）由确定性引擎保障，LLM 仅在意图理解、参数组装等环节发挥自主性。sofagent 的 20/25 条纯 git-diff 规则，正是因为这个原则——不看 Agent 说什么，看 diff 里实际改了什么。
Ontology 建模重心：从名词到动词。行业实施方法论给出了一张清晰的建模重心迁移表——Ontology 的核心价值不在「定义对象」（名词），而在「定义能对对象做什么」（动词）。这一迁移决定了 Ontology 的设计原则：动作类型必须配完整的权限 + 可回滚定义，否则 Agent 执行安全无保障：
| 维度 | 2016 年（传统建模） | 2026 年（Agent 时代） |
|---|---|---|
| 对象类型定义 | 人工维护 schema | 函数契约（机器可读），LLM 读 schema 后自行推导 |
| 语义映射 | 人工翻译字段含义 | 函数参数校验（机器可执行） |
| 动作类型 | 枚举覆盖业务流程 | 动作 + 权限 + 可回滚（Agent 执行安全三件套） |
| 元数据 | 人工打标签 | 运行时身份与留痕（机器自动产生） |
一句话：对象和链接是企业的名词，动作是企业的动词——光有名词不算建模，能对名词做什么才算。 这正是 sofagent v1.3.1 Ontology 本体数据的设计原则——Action Type 作为一等公民，与审计规则对齐，Agent 调用必经 Ontology 定义。
FDE 一线观察指出：AI 项目失败的最根因往往不是技术，而是「什么算成功」从立项起就没有共识——没有共识，工作就变成无人认领的孤儿，三个月后回到原点。这恰恰点出约束层的另一重价值：它不只是「红线」（不许做什么），更是「成功标准」（什么算做完）的可执行载体。sofagent 把「什么算成功」从口头共识写成 fde.md / SKILL.md 里可判定、可复核、可审计的规则，用确定性系统替组织把「成功」锚定下来——这与「智能属于模型、控制属于系统」同构：成功的定义权，必须握在可被验证的系统侧。
定义权的另一面在业务侧。行业本体落地实践把边界表写得很清楚：业务侧定义对象属性、确认流程规则、验收数据质量；IT 侧只做架构设计、数据映射与性能优化，不定义业务规则、不判断数据口径、不决定考核指标。理由很直接：单靠 IT 永远裁决不了「谁的定义对」——答案在业务里，不在数据里。配套组织机制四件：参与边界表（划清能做/不能做）· 三类角色（联络员/业务专家/业务负责人）· 权责对等（只有权没有责 = 参与变提意见；只有责没有权 = 参与变走过场）· 四环节锁定「谁主导」（需求提出与验收归业务）。一条最硬的评审指标：命名符合业务习惯——业务人员看得懂的对象名才活得下去； 它与工程师的规范化命名偏好正面冲突，故要靠治理机制守，而非靠约定。
对约束层的含义两条：① 注入的输入源在业务侧——约束应由业务口径沉淀而来，而非工程师拍脑袋写死在代码里（FDE 进场梳理正是这条的工程实现）；② 争议的正解通常是拆分而非统一——「一个概念被迫服务两个目的」时拆成两个标签，双方的定义就都对。与上文合读即得定义权双面：系统侧管「什么算成功」（可验证、可审计、可复核），业务侧管「语义是什么」（业务裁决、IT 不越位）。
上文讲了知识的三层治理（Ledger-Views-Policy）。但知识不是静态容器——它应该流动。每次 FDE 交付都是一次数据采集，每次采集都让下一代交付更准。这就是飞轮闭环：
交付（每个客户的 .sofagent/ + delivery-report.md）
↓ 结构化沉淀
知识库聚合（knowledge/ 多客户积累）
↓ 领域语料积累
模型精调（QLoRA 企业专属小模型——排期已前移至 [v1.7.0](./changelog/v1.7/v1.7.0.md)）
↓ 模型更准
下一代交付（FDE 拿着更准的模型 + 更丰富的知识库进场）
↓ 循环
飞轮的四个齿轮：
| 齿轮 | 数据形态 | 落盘点 | 当前状态 |
|---|---|---|---|
| ① 交付物 | workflow.yml + ontology + skills/ | .sofagent/ 目录（activate 读它） |
✅ 已实现 |
| ② 离场报告 | FDE 经验（踩坑/调试难点/可复用模式） | delivery-report.md（FDE/templates/） |
✅ 模板已建 |
| ③ 知识聚合 | 多客户报告 → 统一知识库 | knowledge/（Dream Cycle 自动派生） |
✅ 已实现 |
| ④ 模型精调 | 知识库 → QLoRA 训练语料 | sofagent-model CLI |
🟠 排期中（v1.7.0 本地 LoRA 档 + v1.8.0 权重分发） |
为什么离场报告是关键：交付物（①）是结构化的，但 FDE 脑子里的经验（②）是非结构化的——散落在对话、录音、个人笔记里，会随时间流失。delivery-report.md 就是把这个「漏斗」接住：离场时强制回写一份，飞轮才有数据可转。没有它，飞轮缺一齿，转不起来。
与「能力长在代码里」的关系：飞轮闭环不是「把经验写成 prompt 喂模型」——那会被模型吞噬。它是把经验沉淀成结构化数据（workflow 模式 + 调试案例 + 领域本体），最终通过 QLoRA 训进模型权重。经验长在权重里，不长在 prompt 里——这与 §一「为什么不封装成 Skill」同源。
封装进 Subagent 解决了「约束不被文字吞噬」，但水龙头还能进化出第二层能力：自带净水设备——在 Subagent 里内置一个专精于该业务 workflow 的小模型。水龙头不造水（不做通用大模型），但它有自己的滤芯（业务专属小模型）：大厂 LLM 的原水过来，先过一道自己的业务处理，再放给具体业务用。
实现机制（技术路线详见 ROADMAP · 分层模型架构）：基于开源小基座挂业务适配器 QLoRA 精调（4-bit 量化基座 + 低秩适配器，不碰上游蒸馏 / 剪枝），本地小模型即可在消费级硬件上微调与推理，无需 GPU 集群。
后训练视角（概念对齐）：此处「QLoRA 精调」在学术分类上属于领域后训练（domain post-training）——即在开源小基座上做企业侧后训练，而非基模厂商发布前的通用后训练。后训练（post-training）是预训练之后让模型「有用 + 安全」的全部阶段（SFT / RLHF / DPO / GRPO…）的上位概念，精调 / 微调（fine-tuning）是其中一支；QLoRA 又属参数高效微调（PEFT）。 行业共识趋势是「预训练标准化、后训练个性化」：基模商品化后，差异化发生在后训练层，企业把自身 workflow 数据做成领域后训练即护城河——这正是 sofagent「企业专属小模型战略必争」的判断依据。
SFT 与 RAG 的适用边界：知识新增用 RAG（挂在检索层，不动参数），行为固化用 SFT（把企业的风格、流程、判断习惯训进权重）。对应两条产品线：知识层（knowledge/ + 本体数据 + RAG 检索）管「让 Agent 知道企业的业务」，微调层（v3.x QLoRA）管「让模型养成企业的做事方式」——正交不互替。（当前尚未实现 SFT，仅概念准备）
训练数据分拣的安全边界（什么该进权重）：企业微调要模型学会的是领域语言、格式规范、流程口径、判别模式——这些主要在脱敏档和公开档里。而敏感档的内容（客户名单、具体价格、财务数字）恰恰不该进权重：模型逐字记住客户名单不是「更强」，是泄露面变大——模型一被诱导就往外吐。所以「全量训练」往往不是效果更好，是风险更大。分拣的准确含义不是「把敏感数据扔掉」，是「把敏感事实从训练语料挪进知识库」——模型该学的模式一个没少学，不该记的事实一条不记，用时 RAG 检索照样拿得到。**客户名单进权重，客户知道后会翻脸；客户名单进知识库 + 审计链，客户才会买单。 **分拣不是效果妥协，是「什么该记、什么该查」的架构纪律。
- 两个商业动因（数据安全 + 成本，双痛点归一到同一方案）：
- ① 数据安全——数据出去了就回不来：企业财务数据、客户隐私、合同条款、员工信息一旦走大厂 LLM API 处理，理论上就进了模型的训练管线。你无法知道三个月后，是否有人在另一个场景下，用巧妙的 prompt 诱导模型输出你曾经提交过的某条敏感信息。这是所有合规敏感行业（金融/医疗/政府/法律）不敢深度用 AI 的核心原因——不是 AI 不好用，是数据出去了就回不来。
- ② 成本——自建大模型太贵：私有化部署一套大模型，一台至少 4 张 A100/H100 的服务器（数百万起步，最新模型上千万）+ 持续运维 + 模型更新人力。对大多数中小企业，这根本不是选项。
- 归一到同一方案：workflow 专属精调模型用可控成本换可控的数据安全——模型在本地跑，数据不出企业内网，零投喂；窄域基座可以小到一台普通工作站承载，不需要 GPU 集群。领域够窄时，小基座在单一 workflow 的准确率可追平大得多的通用模型（方向性参考，无权威基准实测）。
- 基座选型不预设固定规格：参数量门槛由业务窄域宽度、延迟预算与客户硬件共同决定，不在文档层写死具体模型（同一窄域在不同客户处的可用候选不同）。本地基座的价值是省钱 + 数据不出域，不是某个固定规格。
- 🔴 任务价值分流——代码/强推理直接用最好模型：代码生成、复杂推理、多步规划这类「值得用最强智能」的高价值任务，用户明确直接选用云端最强 LLM（如 Claude / GPT / Gemini），不强行本地化。本地小模型只覆盖「可窄域替代」的业务 workflow 场景；私有部署优先铁律针对业务数据，不与高价值智能任务走云端冲突。云端大厂 LLM 在此类场景是默认路径（非 fallback）。
结论——本地小模型可跑：基于开源小基座 + QLoRA 精调（4-bit 量化基座 + 低秩适配器，比全参微调更轻，Mac Mini 上即可跑，适配器仅几 MB）+ 消费级硬件，业务专属小模型即可在本地微调与推理，无需 GPU 集群；多台设备的价值在推理并发节点，而非训练集群。整个项目对外保持纯 Node/TS 技术栈（训练封装 Python、推理绑定 Node）。具体推理 / 训练框架见 ROADMAP · 分层模型架构（v3.x 远景概述）。
路线已前移（原 v3.x/v4.x 时间线作废，2026-09-26 对齐）：本地推理与权重部署已排进判定底座施工期——v1.7.0 本地 LoRA 档为交付形态下限、v1.8.0 权重分发通路与自带件形态成立、离线介质两档交付（A 安装器档 / B 便携运行时档）同期落地。完整技术骨架见 ROADMAP · 分层模型架构（v3.x 远景概述）。
⚠️ 远期愿景，尚未实现，非当前能力📌 归属边界（与 ROADMAP v1.4.1
1.4.6 排期一致）：后训模块的工程骨架随开源仓交付（编排/审计/沙箱等通用工程能力——开源是信任杠杆，v1.4.11.4.6 六版交付；训练协议三约定 + 预算控制已前移 v1.3.6）——训练资产走商业侧（商业层承载：配方/权重/数据基准 + 规模化运营）——开源管「骨架 + 审计」，商业管「资产 + 运营」。
上文「水龙头自带净水设备」描述的是 sofagent 自身 Subagent 内置专精小模型的单体路线。更远的演化终态是将其平台化：ontology 驱动的后训练模型自动部署——
- sofagent 不再是「自训自用」，而是自动帮企业基于其私有业务做后训练，并把模型部署到企业侧；
- 产品形态从「一套 Harness」升级为「后训练模型自动部署」，交付物是部署在企业侧的定制模型（基于企业自有/通用基座后训练，非 sofagent 自制大模型），使用者是企业客户而非 sofagent 自身；
- 后训练模型的自动化部署能力由约束层 + 进化能力泛化而来（从「自己进化」到「帮企业进化」）。
此为长期目标蓝图，当前完全不具备该能力，仅作为演进方向记录，不视为现状或近期计划。
行业正把「Agent 自进化」（self evolution）推向台面，其核心判断值得吸收：反思与自进化的分界线在于 update——反思只解决这一次任务，自进化必须永久保存修改，解决下一次任务。只有反思没有沉淀的 Agent，干一万次活和第一次没区别；没被记录的经验等于没发生。AI 公司的内部实践正收敛到同一个形态——把「干活 → 记录 → 审查 → 修正」跑成自动循环（AI Loop），且循环本身由 AI 驱动而非人工推动：每轮记录越完整、审查越独立，下一轮的起点就越高。 sofagent 的 FORGE（fresh-eyes 独立审查 + release-gate 发版闸门）正是这个循环的工程实现——自进化不是「模型变聪明」，是「循环在转且每次都留痕」。
自进化从浅到深分五层，sofagent 的覆盖度：
| 层 | 进化什么 | sofagent 对应 | 状态 |
|---|---|---|---|
| L1 记忆 | 记住什么好用（B 数据源比 A 稳） | think.md Ledger + Dream Cycle 每晚知识提取 | ✅ |
| L2 策略 | 规划瘦身（10 步砍到 7 步） | route-policy + evolve 优化 | ✅ 部分 |
| L3 技能 | 成功路径封装成可调用技能 | instinct→skill（三源提取 + 置信度 + 人审聚合，v1.3.5） | ✅ |
| L4 工具 | Agent 自写工具注册进工具箱 | ——（安全语义基建已有：SkillScan 门 + 人审注册） | 🔴 探索方向 |
| L5 模型 | 轨迹→数据集→SFT/RL 改权重 | 训练协议 + 预算 + 约束层工程骨架（v1.4.1~1.4.6 已交付，资产走商业侧） | ✅ 已交付 |
由此而来的产品判断：
-
「做 1000 次任务后是否比第一次更强」是比单次质量更硬的强度指标。审计轨迹、AB 实验胜负、错题本复发率都是现成数据源——把「越用越聪明」做成可观测曲线，而不是营销话术。（边界注：当前进化是设计上自动沉淀——think.md 反思回灌 + evolve 生成候选，但 Dream Cycle 重启即丢、外部 gate CLI 兼容层为可选面（默认 native gate 零依赖），效果是「可积累」而非「全自动闭环」，详见 LIMITATIONS） 执行协议层（v1.5.5）：自进化的循环要转得久，还得转得省——节点内部执行状态机（SKILL.state）把每步上下文压到 P+Σt+ot 三输入，推理轨迹合并后即弃而行为经 wrapToolCall 审计可溯（「轨迹可弃、行为可溯」），长任务的 token 曲线从 O(T²) 拉平到 O(T)——这是循环能在离线算力受限场景持续转的物质基础。
-
L4（自写工具）必须过安全门。Agent 自己写的代码要进生产工具箱，与人类贡献代码同待遇：SkillScan 扫描 + 人审批准 + 审计留痕。没有治理的自进化是漏洞制造机——这是 sofagent 与「放养式自进化」叙事的分野。
-
经验有时间维度（Collector 原则）。执行记录 ≠ 实际结果——交付瞬间学不到「上线后出了什么问题、方案被怎么改、决策最终带来什么影响」；训练数据获得时间维度后，过去的成功不再被当成永久正确的答案。这是 v1.5.9 验证器老化检测的上位叙事：老化检测管「经验失效可发现」，Collector 管「后果持续回流」——审计链（append-only + 因果边）正是那条「跨越任务、人员、模型版本」的连续性载体。
-
进化必须保多样性——「锐化」与「泛化」的平衡有量化依据。RL 后训练会压缩解的覆盖（pass@k 随 k 增大反而被基座超越），ES 却同时提升 pass@1 与 pass@k——RL 是「低熵地确信错」，ES 是「高熵地存疑」（基准实测细节见 VALIDATION，arXiv 2608.12679）。经验沉淀（think.md → knowledge/）应保留多解法谱系而非收敛到单一「最优解」，Dream Cycle 蒸馏保留失败路径记录，就是给下一轮进化留分叉。
叙事边界（冻结声明）：五层谱系是分析框架不是扩张路线图——本叙事冻结在上表覆盖度，L4 / L5 的叙事面以其实际交付为准（资产走商业侧，开源叙事止步于「管道与协议」）。新进化概念须先有对应排期或实证，再进本节——防「叙事跑在实现前面」。
RSI 三级判据（行业坐标系）：行业对递归自我改进（RSI）的最新分级——弱 RSI（保留一次自我改进：改 prompt/记忆并留存）/ 中等 RSI（改进「产生下一次改进的机制」本身）/ 强 RSI（自定义问题与研究方向，当前无公开系统能做到）。对位：五层谱系的 L1-L3（记忆/策略/技能）≈ 弱 RSI——改进发生在内容层；L5 排期中的「轨迹→数据集→权重」走完才有中等 RSI 的入场券（改进机制本身可被改进）；强 RSI 不在叙事范围（叙事边界冻结声明照常生效）。 行业实证同时给出一条硬边界：自提升仅在有廉价验证器的域成立（代码/数学——测试即验证），开放式域必须人审兜底——这与上文「L4 必须过安全门」同源（arXiv 2609.06396，自提升在代码与封闭式科学推理域验证，Harness 路线对前沿 API 模型 +7.3 分；验证差距判据综述见 VALIDATION · Meta-RSI）
| 你是谁 | 怎么用 sofagent |
|---|---|
| 懂电脑的用户 | 正常安装流程，部署到电脑上就能用 |
| 什么都不懂的用户 | 给他配个 U 盘——sofagent + OpenClaw + 联邦密钥全在盘上，插上就能用 |
| 无头设备 | 把 U 盘插上去就别拔了——Agent 一直在联邦里跑 |
离线介质的身份语义（重定位 · 2026-09-26）：U 盘退役「物理身份载体/完整离线节点」旧叙事，重定位为 DSH 节点 + 判定件的交付介质（两档：安装器档 / 便携运行时档，见 v1.8.0）——介质承载的是「被治理的判定能力」，治理身份仍在企业侧的审计链与权限体系，不随介质转移。
FDE 不一定是你的 job title，但它是 sofagent 的核心能力模型。 产品的终极目标不是培养更多 FDE，而是让每个用户都拥有 FDE 的工作方式。
FDE 的核心是三个能力：
| 能力 | 含义 | sofagent 怎么做 |
|---|---|---|
| 掌握完整上下文 | 理解企业的全部业务关联 | Ontology 统一层 + 记忆系统——让你拿到全量业务世界模型 |
| 打破岗位边界 | 不按岗位分工做事，按交付结果调资源 | SkillHub——单人借 Agent Skill 调动多岗能力，一个命令串起采购→审批→财务 |
| 对结果负责 | 可追溯、可验证、可问责 | 审计模块 + 验证门控——每次变更都有 git diff 硬证据，每次操作都可追溯 |
FDE 的双重身份——「人肉反向传播」。Palantir 把 FDE 在内部定位为 "human equivalent of backpropagation"（产品研发的人肉反向传播）——既是客户现场的交付工程师，也是产品研发的反馈源。客户同时在为交付与产品研发买单。这一判断解释了为什么 FDE 天然是双向的：每次现场交付都是对产品的一次梯度信号——「这里缺什么原语」「那个口径有分歧」「这个动作没人能定义清楚」。 sofagent 把这条双向职责机制化——进化能力（daemon 巡检 + think.md 反思 + Dream Cycle 知识提取）让经验回流不依赖个人自觉，FDE 离场后梯度信号仍在跑。
FDE 入场时，不搭交互页面。做的事是：梳理 workflow 节点 → 定义输出终点 → 注入 AI 知识库。但产品化之后，用户自己也能做——这份文档就是教你怎么做。
部署不是终点——系统必须学会「说话」。sofagent 的进化能力不只是优化规则，还定期生成价值证明报告（审计守护周报、知识库增长月报、无 FDE 对照季报），让客户持续感知到 FDE 部署的底座在产生价值。FDE 的成功悖论是：系统跑得越稳，客户感知越弱（详见 FDE/GUIDE.md §5.10 离场）。持续存在感是设计需求，不是营销策略。
sofagent 内核（约束注入链 + 审计能力 + FDE 能力）是给开发者用的。产品化交给非技术买家时，需要一层不同的外壳——这层外壳的哲学，和「持续存在感是设计需求」同构：只是场景从 Agent 自己，扩到 buyer 看 Agent。
- 卖能力，不卖工时：FDE 不是一种岗位 / 驻场服务，而是企业该有的一种能力，用 Agent / sub-agent / 产品化封装交给企业，企业自己用、自己落地 AI 化（见本节 FDE 视角）。营收从「顾问工时」变成「企业数 × 订阅」，可规模化。
- 为什么需要 dashboard：sofagent 自身 LUI-first（语言即界面）——但 Agent 的 LUI + LLM 会「吞噬一切」，非专家买家看不到持久状态、没有成就感锚点。所以产品化必须带一个轻量 dashboard 作为自有视图（审计状态 / AI 化进度 / 合规月报），让买家随时看得见「我公司 AI 化到哪了」。这与「持续存在感是设计需求」一致——只是这次是 buyer 的持续存在感。
- 为什么用 MCP：dashboard 是轻量化的，靠 MCP 配合——MCP 作为向外接的桥，让客户已有的 Agent / 你的 sub-agent 把数据喂给 dashboard 后端。MCP 是桥、不是唯一入口；dashboard 必须自己拥有。
- 零 GUI 铁律不变：上面的 dashboard 是只读可见视图（看审计状态 / 进度 / 月报），不是用来下令的图形界面——下令仍走 LUI。这与 §二「零 GUI」不矛盾。
- open-core 双轨：内核（审计规则 / FDE 工作流 / 编排）继续 MIT 开源做信任资产；商业化只卖那层 dashboard（控制台 / 合规月报 / 告警）。开源负责让人信，闭源负责让人付。
- 控制平面打法：底层 Agent 智能随便换（OpenClaw / 客户自选 / 大厂），治理与真相（策略谁配、审计链长啥样、Agent 注册在哪）永远在 sofagent 的 dashboard 里。sofagent 不做 Agent 运行，只管住跑任务的 Agent——这是它能被信任的前提。
FORGE 是 sofagent 的自迭代工具链：Agent 写代码、Agent 审计、Agent 审查——不是隐喻，是真实运行的工程闭环。核心纪律是评判者与执行者分离——银行转账，录入和复核是两个人。工程师 Agent 看自己写的代码不是审查，是自我说服。
| Loop | 角色 | 职责 |
|---|---|---|
| fresh-eyes-loop | A（审查者，只读工具）+ B（工程师，写工具） | A/B 双盲质量审查循环（常规 12 视角 / 全量 23 视角） |
| release-gate-loop | V（验证者，只读工具） | 发版闸门：从审查到发版的全流程验证 |
「新鲜眼睛」的纪律不靠模型自觉，而靠流程结构保证：每步独立子进程（零上下文）+ 独立 prompt + 异构双模型（审查者用深度推理模型、工程师用编码强项模型）。
- 环境配置与模型接入：
FORGE/quick-start.md - 循环协议：
FORGE/SKILL/fresh-eyes-loop/loop.md/FORGE/SKILL/release-gate-loop/loop.md - 沉淀的经验教训：
FORGE/lessons/index.md
sofagent 的版本演进不是拍脑袋排的——它遵循 Agent 工程的生产级建设顺序：
第一步：建立可靠约束层（v0.91–v1.0）
→ 审计能力 + 约束注入链 + 回溯能力
→ 让 Agent 在一个稳定、受控、可恢复的环境中工作
第二步：为高价值失败增加 Loop（v1.1–v1.2）
→ fresh-eyes-loop（质量循环）+ release-gate-loop（发版闸门）+ sustain（持续优化）
→ 让每次失败获得新证据，在明确边界内接近终点
第三步：将稳定的复杂路径固化为 Graph（v1.3+）
→ 约束层（内部为 LangGraph DAG）并行调度 + 多 Agent 协作 + 检查点恢复
→ 把分支、并行、审批、恢复路径变成可检查的系统结构
原则：架构复杂度应该来自已经观察到的真实需求，而不是来自对「高级 Agent」的想象。优先建设约束层解决工具、状态、权限、恢复和可观测性；当单次结果经常接近正确却需要测试和修订才能稳定交付时，再增加 Loop；只有任务出现明确分支、并行工作、多个专家、人工审批和恢复路径时，才值得引入 Graph。
| 想法 | 为什么不 |
|---|---|
| 自研通用行为验证器 | 通用 Agent 行为面平台原生已覆盖；领域专属产出判据必须自建——由 eval 四工具承载，上游门禁全绿不能替代它（判据分层与外部结构性答案见 LIMITATIONS「复盘评分是 LLM 自评」节） |
| 另起执行面 | 自迭代/自生成的可执行定义（插件、循环体、判定件）不许有平行执行系统——必须挂进同一张执行图与同一份事件日志，与手写产物同等受审；跑在别处=治理失效 |
| 图形界面/仪表盘 | LUI-first——语言就是界面（只读终端 Dashboard 见 §六，是「只读可见视图」不是「下令用的交互式 GUI」——禁的是后者，前者是产品化外壳） |
| 全栈企业 Agent 平台 | 不做 扣子（Coze，字节跳动） 竞品——sofagent 是独立底线守卫层 |
| think.md 强制 gate | 强制会导致 Agent 用垃圾内容填模板 |
| 记忆压缩自动化 | 每个 Agent 有自己的记忆 |
| Connector | sofagent 是约束层 + 审计能力，不是自动化流水线 |
| Workflow Graph → Ontology Graph 单向转换 | 转换丢访谈中的隐性知识，本体沦为工作流的副产品——workflow（流转）与 ontology（语义）必须从同一次 FDE 访谈并行产出、SHACL 互相校验 |
| 把 DSH 当唯一执行层 | 企业命脉不押单一运行时——编排层 LangGraph 长期不换，执行层走 ExecutionBackend 接口（DSH 默认 / createReactAgent fallback / 三平台可选）。 |
| 治理逐节点插桩 | 治理是事件域横切面，不是节点附件——挂 tools/result、turn-stopping、approval seam 一次即全域生效，逐节点插桩是把约束层降格为工具配件 |
注：「长期不换」是架构级取舍非永久承诺（与 ARCHITECTURE · 四层运行形态 同口径）——只承诺「换它 = 放弃确定性审计」这一代价显式化
| 文档 | 为什么读 |
|---|---|
| README.md | 项目概览——它是什么 |
| HANDBOOK.md | 用户手册——怎么用 |
| ARCHITECTURE.md | 架构设计——怎么设计 |
| DEVELOPMENT.md | 开发者文档——怎么参与 |
| ROADMAP.md | 路线图——过去和未来 |
| CHANGELOG.md | 版本历史——每个版本做了什么 |
读完这份文档，你应该能回答：sofagent 为什么存在、它为谁服务、它的边界在哪。 如果还有疑问——不是你的问题，是这份文档没写好。提 Issue。
五条核心结论：① Conway 定律反转——Agent 架构开始反向塑造企业组织形态（阿里 OPT：单人 + Agent Skill + 企业系统闭环完成多岗工作）；② 部门消亡的微观机制——部门是「人的能力局限 + 利益局限」的产物，AI 两个前提都没有 ⇒ 组织走向 GitHub 式协作底座（按最小工作单元组织，人 + AI 跨树提 PR，机器审阅门把关） ③ Coase 定理反转——Agent 把内部协调成本降为零时，企业边界模糊，「企业」从组织结构变成 Agent 能力矩阵；④ sofagent 终局 = Ontology（业务世界模型）+ SkillHub（跨岗能力）+ 审计能力（责任确权）= 单人 + 硅基的最小闭环单元替代传统多部门协作 ；⑤ 完整论证全文见归档。
行业印证与生态定位 — sofagent 的设计直觉如何被行业验证（Palantir Ontology / Harness Engineering / a16z 七法则 / DeerFlow / Omnigent / OpenFDE 等），以及 Agent 生态三层模型中 sofagent 的位置，详见独立文档 VALIDATION.md。