{ "page": { "slug": "agent-first-data-protocol-whitepaper-v1", "project_key": "agent-first-data-protocol", "customer": "TokenPilot / 马骋", "domain": "企业 Agent 底层架构 / 数据协议优先", "title": "Agent-First Data Protocol 白皮书", "subtitle": "企业 Agent 不是会聊天的工作台，而是以 SQL 管事实、Bash/CLI 管动作、协议化交付物管结果、权限 token 管边界的底层系统。", "version_label": "v1 · SQL-to-HTML 白皮书", "audience": "internal_strategy", "renderer": "standard_presentation", "status": "published", "payload": { "blocks": [ { "id": 1, "props": { "badge": "Agent-First Data Protocol · SQL-to-HTML v1", "metrics": [ { "label": "CTX 已登记资产", "value": "18,982" }, { "label": "Agent 原生入口", "value": "SQL + CLI" }, { "label": "交付物源头", "value": "PostgreSQL" }, { "label": "系统原则", "value": "UI Last" } ], "summary": "这套路线把企业资产、业务事实、工具动作和交付物统一转成 Agent 可消费的协议：SQL 是事实与计算平面，Bash/CLI 是行动平面，权限 token 是边界平面，HTML/报告/看板是渲染平面。" }, "title": "企业 Agent 的底层不是 UI，而是数据与执行协议", "subtitle": "Agent first, human verified.", "block_type": "hero", "sort_order": 10 }, { "id": 2, "props": { "after": [ "先做协议，再按需渲染 UI。", "先服务 Agent 的确定性消费，再给人看结果。", "交付物是数据库中的版本化资产，可复算、可审计、可再渲染。", "Agent 通过 CTX/DW/sph 直接找到资产、拿到数据、调用工具、生成结果。" ], "cards": [ { "items": [ "一等公民是人：先设计菜单、按钮、页面、流程和工作台。", "Agent 只能作为附属入口，被迫适配既有人用系统。", "API、数据导出、自动化脚本通常是补丁，不是底座。", "系统好不好，往往由 UI 评审、功能清单和协同入口决定。" ], "title": "传统企业软件的默认假设" }, { "items": [ "一等公民是 Agent：先让 Codex、Claude、Reasonix 能读、能查、能跑、能交付。", "人从日常操作者退为授权者、验收者和最终决策者。", "上游协议由下游 Agent 的消费效率反向定义。", "系统好不好，由通用 Agent 能否少解释、少上下文、少泄露地完成任务决定。" ], "title": "Agent-First 系统的默认假设" } ], "before": [ "先做 UI，再补接口。", "先服务人的操作体验，再考虑 Agent 能否消费。", "每个客户交付物独立制作，难复用、难版本化。", "Agent 经常需要人反复告诉它路径、连接、规则和上下文。" ] }, "title": "核心判断：存量软件是 Human-First，我的系统是 Agent-First", "subtitle": "这不是交互偏好，而是系统第一性原理的变化。", "block_type": "context", "sort_order": 20 }, { "id": 3, "props": { "after": [ "把 Agent 当成企业软件的新消费者。", "让 Agent 面对统一的数据平面、命令平面和交付协议。", "用确定性、审计性、可复现性定义企业级。" ], "cards": [ { "items": [ "系统首先要让 Agent 稳定干活，而不是让人先在 UI 里操作得舒服。", "人的关键角色是授权、验收和决策，而不是搬运、查找、复制和重复操作。", "对人的页面是结果层，不是底层。" ], "title": "1. Agent First, Human Verified" }, { "items": [ "先定义 Agent 能消费的协议，再考虑页面如何呈现。", "CTX 协议解决资产发现，DW 协议解决受控取数，sph 协议解决交付物渲染。", "UI 是 renderer；协议和数据表才是 source of truth。" ], "title": "2. Protocol First, UI Last" }, { "items": [ "SQL 是事实、关系、指标、规则和证据的母语。", "Bash/CLI 是文件、进程、系统工具、脚本编排和交付动作的母语。", "单个 CLI 是动作，Bash 是动作之间的组合语言。" ], "title": "3. SQL for Facts, Bash/CLI for Actions" }, { "items": [ "交付是否成立，看结果能否被生成、复现、审计和下钻。", "交互体验重要，但不应先于数据协议和执行协议。", "越靠近底层，越应该减少为迎合人的视觉和交互而做的冗余设计。" ], "title": "4. Result First, Interaction Second" } ], "before": [ "把 Agent 当成聊天入口或协同插件。", "让 Agent 在散乱的人用系统之间猜路径、猜字段、猜规则。", "用 UI 复杂度包装企业级。" ] }, "title": "四条底层原则", "subtitle": "把“执念”升级成方法论。", "block_type": "context", "sort_order": 30 }, { "id": 4, "props": { "scenarios": [ { "ai": [ "资产统一登记到 PostgreSQL-backed ODS。", "用 ctx search/stats 按资产类型、别名、客户和项目提示快速检索。", "让 Agent 从 SQL 化资产层拿上下文。" ], "tag": "资产协议", "name": "CTX Asset ODS：全服务器资产 SQL 化", "owner": "资产发现 / Agent 上下文", "price": "底座能力", "manual": [ "人反复告诉 Agent 到哪里找文件、哪个技能该用、哪个 CLI 可用。", "Agent 每次从零搜索文件系统，召回慢且容易漏。", "历史会话、技能、数据连接和交付物分散在不同目录。" ], "people": "减少大量人工解释", "evidence": [ "ctx stats 显示 registered_assets=18,982。", "已登记 chat_session=656、cli=120、sql=119、data_connection=8。", "CTX README 明确目标：让 Agent 通过 SQL-backed search 找上下文，而不是猜文件路径。" ], "upstream": "文件、目录、技能、CLI、数据连接、会话日志、企微消息、交付产物", "downstream": "Codex/Claude 通过 ctx search/stats 发现上下文，不再反复猜路径" }, { "ai": [ "页面源写入 presentation_hub.pages。", "按 hero/context/scenario_grid/roi/roadmap/echarts 等块渲染。", "同步生成每页 package schema：manifest、blocks、evidence、metrics、scenarios、rendered_html。" ], "tag": "结果协议", "name": "SQL Presentation Hub：交付物 SQL-to-HTML", "owner": "商务材料 / 客户演示 / 证据页面", "price": "交付协议", "manual": [ "每个客户演示单独写 HTML。", "页面格式、内容、证据和版本混在一起，难复用。", "结果无法被 SQL 查询、无法稳定版本化。" ], "people": "避免每个客户重写一套 HTML", "evidence": [ "现有页面包括 ruide-ai-project-v1、ruide-pcb-review-v1、ruide-reconciliation-huimao-v1。", "sph validate 显示现有页面包 contract_ok=true。", "本白皮书自身也以 SQL-to-HTML 页面方式交付。" ], "upstream": "业务证据、指标、规则、场景、页面块、渲染配置", "downstream": "公网 HTML、JSON API、页面包 schema、后续 PPT/报告/看板 renderer" }, { "ai": [ "平台变成 Agent 的受控数据后端，而不是只给人看的前端。", "通过 schema/table 级短期 token 暴露只读数据能力。", "Agent 通过 dw CLI 使用 token 拉数据，跳开裸数据库密码。" ], "tag": "权限边界", "name": "DataWeave Agent 化：受控数据出口", "owner": "企业数据后端 / Agent 数据消费", "price": "数据协议", "manual": [ "人复制连接配置，但不能安全暴露数据库密码。", "每次给 Agent 数据都要重新解释连接、schema、表和权限边界。", "大客户数据无法随意把 DB 凭证交给任务 Agent。" ], "people": "减少人工拷贝连接和重复授权", "evidence": [ "2026-06-09 已增加 data access token 迁移。", "会议中明确提出 24/48 小时或 7 天 schema/table 级只读 token。", "定位从“前端平台”转向“Agent 可消费的数据内核”。" ], "upstream": "数据库连接、schema、表、查询、权限、临时访问 token", "downstream": "dw CLI/API 给下一个 Agent 拉取数据" } ] }, "title": "已落实的项目：从理念到可运行底座", "subtitle": "这些不是概念原型，而是已经在服务器上跑起来、被 Agent 真实消费的项目。", "block_type": "scenario_grid", "sort_order": 40 }, { "id": 5, "props": { "scenarios": [ { "ai": [ "不从人用界面理解 PCB，而是把板、层、线、元件、坐标、测试点还原成数据。", "把 46 条审核标准投射到结构化规则和证据表。", "用 SQL-to-HTML 生成带坐标和违规点的评审工作台。" ], "tag": "结构化突破", "name": "PCB 工艺评审：绕开人用设计软件，接管底层数据", "owner": "瑞德智能 / 工程与品质", "price": "可立项客户场景", "manual": [ "人必须理解专用 CAD/PCB 软件和专有格式。", "评审依赖工程经验、规则散落、证据难复现。", "客户看到的是设计软件表层，Agent 难直接接管。" ], "people": "从专用软件依赖转为数据化审查", "evidence": [ "已生成 ruide-pcb-review-v1 页面。", "评审工作台中规则、结论、坐标和图形对象来自 SQL。", "客户侧已认为该方向具备立项可能。" ], "upstream": "PCB Doc/设计数据、坐标、走线、元件、测试点、审核规则", "downstream": "SQL 化评审证据、违规点坐标、可视化工艺评审页面" }, { "ai": [ "把客户 Excel 表头映射到 ODS 字段。", "用 SQL 表达对账数量、对账单价、对账金额和差异。", "自动生成带规则、字段映射、明细表和风险结论的页面。" ], "tag": "财务数据化", "name": "辉贸客户对账：从 ODS 到差异结论", "owner": "瑞德智能 / 财务与 IT", "price": "演示转交付样例", "manual": [ "财务人员手工理解 Excel 表头和业务规则。", "人工计算单价差、金额差和风险等级。", "对账结果难解释、难复算、难追溯。" ], "people": "减少人工 Excel 对账", "evidence": [ "已生成 ruide-reconciliation-huimao-v1 页面。", "样例中字段覆盖 31/31，中高风险 4 行，差异合计 842.90。", "页面不是死 HTML，而是由 ODS 映射、规则和样例行驱动。" ], "upstream": "ERP/ODS 销售明细、客户确认价、未开票数量、销货单号、品号", "downstream": "差异表、风险标记、对账规则、可下钻 HTML 页面" }, { "ai": [ "把每个场景统一表达为上游、下游、人工模式、AI 模式、证据和报价。", "把商务呈现转成 SQL Presentation Hub 页面包。", "让后续版本变成数据表 v1/v2/v3，而不是重做页面。" ], "tag": "商务交付", "name": "瑞德 AI 场景化立项：从数据治理到商务呈现", "owner": "瑞德智能 / 多部门", "price": "65 万元方案样例", "manual": [ "每个场景单独梳理材料、截图、PPT 和页面。", "报价、ROI、证据和实施路径分散维护。", "客户演示依赖一次性手工材料。" ], "people": "把分散需求变成可治理场景包", "evidence": [ "已生成 ruide-ai-project-v1 页面。", "六个场景、报价、ROI 和路线图均以同一结构表达。", "会议中明确提出“拿到数据就能出 demo”的管线目标。" ], "upstream": "BOM、环保资料、IQC、PCB、采购交期、财务对账等场景数据", "downstream": "场景证据、报价、ROI、路线图、客户演示页面" } ] }, "title": "客户场景案例：先还原成数据，再让 Agent 接管", "subtitle": "判断一个场景能不能做，不取决于我懂不懂行业软件，而取决于它能不能被还原成结构化数据。", "block_type": "scenario_grid", "sort_order": 50 }, { "id": 6, "props": { "charts": [ { "note": "从人用系统到 Agent-first 系统：UI 从底座退为最后的 renderer。", "option": { "radar": { "indicator": [ { "max": 10, "name": "Agent 可消费" }, { "max": 10, "name": "可复现" }, { "max": 10, "name": "可审计" }, { "max": 10, "name": "权限边界" }, { "max": 10, "name": "交付复用" }, { "max": 10, "name": "UI 优先" } ] }, "legend": { "data": [ "传统 Human-First", "Agent-First Data Protocol" ] }, "series": [ { "data": [ { "name": "传统 Human-First", "value": [ 3, 4, 4, 5, 3, 9 ] }, { "name": "Agent-First Data Protocol", "value": [ 9, 9, 8, 8, 9, 4 ] } ], "type": "radar" } ], "tooltip": { "trigger": "axis" } } }, { "note": "四个平面对应四类协议：事实、动作、边界、结果。", "option": { "series": [ { "data": [ { "name": "企业 Agent 底层系统", "children": [ { "name": "SQL 事实平面", "children": [ { "name": "资产" }, { "name": "指标" }, { "name": "规则" }, { "name": "证据" } ] }, { "name": "Bash/CLI 行动平面", "children": [ { "name": "ctx" }, { "name": "dw" }, { "name": "sph" }, { "name": "脚本编排" } ] }, { "name": "Token 边界平面", "children": [ { "name": "schema 级" }, { "name": "table 级" }, { "name": "短期只读" }, { "name": "审计" } ] }, { "name": "Renderer 结果平面", "children": [ { "name": "HTML" }, { "name": "报告" }, { "name": "看板" }, { "name": "API" } ] } ] } ], "roam": true, "type": "tree", "label": { "align": "right", "position": "left", "verticalAlign": "middle" }, "leaves": { "label": { "align": "left", "position": "right", "verticalAlign": "middle" } }, "orient": "LR" } ], "tooltip": { "trigger": "item" } } } ] }, "title": "架构图：企业 Agent 的四个平面", "subtitle": "不是做一个更复杂的工作台，而是重建 Agent 可消费的数据与命令平面。", "block_type": "echarts", "sort_order": 60 }, { "id": 7, "props": { "after": [ "把 Agent 当成企业软件的新消费者，重建可消费底座。", "让人的工作台退到渲染和验收层。", "通过真实客户问题的穿透速度和交付转化率竞争。" ], "cards": [ { "items": [ "重点在 IM、办公入口、协同工作台、应用集成和人用流程。", "价值是降低人的使用门槛，适合覆盖大量员工和既有办公生态。", "风险是 Agent 仍然依赖散乱数据、弱权限边界和不可复现流程。", "容易把企业级误解为 UI 丰富、协同复杂、入口统一。" ], "title": "入口型 Agent" }, { "items": [ "重点在数据协议、命令协议、权限协议和交付协议。", "价值是让通用 Agent 稳定接管真实业务事实和业务动作。", "判断标准是能否把客户真实问题快速转成数据、规则、证据和结果。", "企业级不由 UI 定义，而由确定性、审计性、可复现性和权限边界定义。" ], "title": "底座型 Agent" } ], "before": [ "把 Agent 做成一个更会聊天、更会协同的工作台。", "在存量系统上增加 Agent，让 Agent 迁就人的操作路径。", "通过产品入口竞争。" ] }, "title": "与入口型企业 Agent 的根本差异", "subtitle": "不是否定入口和协同，而是明确底座和入口不是同一层。", "block_type": "context", "sort_order": 70 }, { "id": 8, "props": { "payback": "每个客户场景复用", "benefits": [ "场景选择更清晰：能数据化表达就接，纯感觉、强非确定性、无法结构化的场景少碰。", "交付路径更短：从数据治理直接到 SQL-to-HTML 页面，而不是每次重新做材料。", "Agent 使用更稳定：CTX 解决找上下文，DW 解决拿数据，sph 解决出结果。", "客户沟通更有穿透力：不必先成为行业软件专家，而是证明能把行业对象还原为数据并产生结果。", "长期资产可沉淀：每次交付都会增加资产、协议、模板、规则和案例，而不是只留下一个死页面。" ], "investment": "深耕 SQL/CLI/协议", "optimistic": "形成企业 Agent 底座", "conservative": "更快做出 Demo" }, "title": "价值判断：为什么这条路能持续拿结果", "subtitle": "它把客户问题从“要不要懂行业软件”降维到“能不能结构化表达”。", "block_type": "roi", "sort_order": 80 }, { "id": 9, "props": { "phases": [ { "name": "Phase 1", "focus": "协议补全：让 Agent 少解释也能消费", "items": [ "为 CTX 增强概念词、同义词、会话摘要和任务意图召回。", "把 sph 页面协议继续稳定为可复用的页面包模型。", "把 DataWeave 的 schema/table 级短期 token 跑通最小可用闭环。" ] }, { "name": "Phase 2", "focus": "案例沉淀：每个客户场景都变成资产", "items": [ "把 PCB、对账、BOM、环保资料、采购交期等场景统一沉淀为模板。", "每个模板包含数据接入、规则、证据、交付页面和验收方式。", "建立 Agent 消费失败反馈机制，让 Codex/Claude 反向定义上游协议改进。" ] }, { "name": "Phase 3", "focus": "产品表达：从工具链升级为底座叙事", "items": [ "对外表达为 Agent-First Data Protocol / 数据协议优先的企业 Agent 底座。", "保留 UI 作为客户验收与演示层，不让 UI 主导底层设计。", "用真实客户案例证明：同样业务问题，谁能更快数据化、规则化、交付化。" ] } ] }, "title": "接下来 12 个月的深耕路线", "subtitle": "不要急着产品化 UI，先把 Agent 消费路径打穿、打稳、打可复用。", "block_type": "roadmap", "sort_order": 90 } ], "version": { "slug": "agent-first-data-protocol-whitepaper-v1", "title": "Agent-First Data Protocol 白皮书", "subtitle": "知行合一：本白皮书本身不是 Markdown，而是 SQL Presentation Hub 中的一页数据化交付物。" }, "evidence": [ { "id": 1, "title": "CTX Asset ODS", "summary": "本地资产注册与搜索 CLI，目标是让 Agent 通过 SQL-backed search 找上下文。", "source_ref": "/home/claw/asset-ods/README.md", "source_type": "local_project" }, { "id": 2, "title": "SQL Presentation Hub", "summary": "PostgreSQL 是展示源，不复制 HTML；页面由 presentation_hub.pages 渲染。", "source_ref": "/home/claw/projects/sql-presentation-hub/README.md", "source_type": "local_project" }, { "id": 3, "title": "腾讯会议逐字稿", "summary": "围绕 SQL 化、SQL-to-HTML、DataWeave 给 Agent 消费和短期 token 的策略讨论。", "source_ref": "/home/claw/tmp/meeting_zou/20260609224633-马骋的快速会议-逐字稿文本-1.txt", "source_type": "meeting_transcript" } ] }, "source_note": "基于 2026-06-09 至 2026-06-10 关于 CTX、SQL Presentation Hub、DataWeave Agent 消费、PCB/对账客户案例的讨论与会议逐字稿整理；页面源写入 presentation_hub.pages。", "created_at": "2026-06-10 00:53:17.670122+08:00", "updated_at": "2026-06-10 00:53:48.527251+08:00" }, "version": { "slug": "agent-first-data-protocol-whitepaper-v1", "title": "Agent-First Data Protocol 白皮书", "subtitle": "知行合一：本白皮书本身不是 Markdown，而是 SQL Presentation Hub 中的一页数据化交付物。" }, "blocks": [ { "id": 1, "block_type": "hero", "title": "企业 Agent 的底层不是 UI，而是数据与执行协议", "subtitle": "Agent first, human verified.", "props": { "badge": "Agent-First Data Protocol · SQL-to-HTML v1", "metrics": [ { "label": "CTX 已登记资产", "value": "18,982" }, { "label": "Agent 原生入口", "value": "SQL + CLI" }, { "label": "交付物源头", "value": "PostgreSQL" }, { "label": "系统原则", "value": "UI Last" } ], "summary": "这套路线把企业资产、业务事实、工具动作和交付物统一转成 Agent 可消费的协议：SQL 是事实与计算平面，Bash/CLI 是行动平面，权限 token 是边界平面，HTML/报告/看板是渲染平面。" } }, { "id": 2, "block_type": "context", "title": "核心判断：存量软件是 Human-First，我的系统是 Agent-First", "subtitle": "这不是交互偏好，而是系统第一性原理的变化。", "props": { "after": [ "先做协议，再按需渲染 UI。", "先服务 Agent 的确定性消费，再给人看结果。", "交付物是数据库中的版本化资产，可复算、可审计、可再渲染。", "Agent 通过 CTX/DW/sph 直接找到资产、拿到数据、调用工具、生成结果。" ], "cards": [ { "items": [ "一等公民是人：先设计菜单、按钮、页面、流程和工作台。", "Agent 只能作为附属入口，被迫适配既有人用系统。", "API、数据导出、自动化脚本通常是补丁，不是底座。", "系统好不好，往往由 UI 评审、功能清单和协同入口决定。" ], "title": "传统企业软件的默认假设" }, { "items": [ "一等公民是 Agent：先让 Codex、Claude、Reasonix 能读、能查、能跑、能交付。", "人从日常操作者退为授权者、验收者和最终决策者。", "上游协议由下游 Agent 的消费效率反向定义。", "系统好不好，由通用 Agent 能否少解释、少上下文、少泄露地完成任务决定。" ], "title": "Agent-First 系统的默认假设" } ], "before": [ "先做 UI，再补接口。", "先服务人的操作体验，再考虑 Agent 能否消费。", "每个客户交付物独立制作，难复用、难版本化。", "Agent 经常需要人反复告诉它路径、连接、规则和上下文。" ] } }, { "id": 3, "block_type": "context", "title": "四条底层原则", "subtitle": "把“执念”升级成方法论。", "props": { "after": [ "把 Agent 当成企业软件的新消费者。", "让 Agent 面对统一的数据平面、命令平面和交付协议。", "用确定性、审计性、可复现性定义企业级。" ], "cards": [ { "items": [ "系统首先要让 Agent 稳定干活，而不是让人先在 UI 里操作得舒服。", "人的关键角色是授权、验收和决策，而不是搬运、查找、复制和重复操作。", "对人的页面是结果层，不是底层。" ], "title": "1. Agent First, Human Verified" }, { "items": [ "先定义 Agent 能消费的协议，再考虑页面如何呈现。", "CTX 协议解决资产发现，DW 协议解决受控取数，sph 协议解决交付物渲染。", "UI 是 renderer；协议和数据表才是 source of truth。" ], "title": "2. Protocol First, UI Last" }, { "items": [ "SQL 是事实、关系、指标、规则和证据的母语。", "Bash/CLI 是文件、进程、系统工具、脚本编排和交付动作的母语。", "单个 CLI 是动作，Bash 是动作之间的组合语言。" ], "title": "3. SQL for Facts, Bash/CLI for Actions" }, { "items": [ "交付是否成立，看结果能否被生成、复现、审计和下钻。", "交互体验重要，但不应先于数据协议和执行协议。", "越靠近底层，越应该减少为迎合人的视觉和交互而做的冗余设计。" ], "title": "4. Result First, Interaction Second" } ], "before": [ "把 Agent 当成聊天入口或协同插件。", "让 Agent 在散乱的人用系统之间猜路径、猜字段、猜规则。", "用 UI 复杂度包装企业级。" ] } }, { "id": 4, "block_type": "scenario_grid", "title": "已落实的项目：从理念到可运行底座", "subtitle": "这些不是概念原型，而是已经在服务器上跑起来、被 Agent 真实消费的项目。", "props": { "scenarios": [ { "ai": [ "资产统一登记到 PostgreSQL-backed ODS。", "用 ctx search/stats 按资产类型、别名、客户和项目提示快速检索。", "让 Agent 从 SQL 化资产层拿上下文。" ], "tag": "资产协议", "name": "CTX Asset ODS：全服务器资产 SQL 化", "owner": "资产发现 / Agent 上下文", "price": "底座能力", "manual": [ "人反复告诉 Agent 到哪里找文件、哪个技能该用、哪个 CLI 可用。", "Agent 每次从零搜索文件系统，召回慢且容易漏。", "历史会话、技能、数据连接和交付物分散在不同目录。" ], "people": "减少大量人工解释", "evidence": [ "ctx stats 显示 registered_assets=18,982。", "已登记 chat_session=656、cli=120、sql=119、data_connection=8。", "CTX README 明确目标：让 Agent 通过 SQL-backed search 找上下文，而不是猜文件路径。" ], "upstream": "文件、目录、技能、CLI、数据连接、会话日志、企微消息、交付产物", "downstream": "Codex/Claude 通过 ctx search/stats 发现上下文，不再反复猜路径" }, { "ai": [ "页面源写入 presentation_hub.pages。", "按 hero/context/scenario_grid/roi/roadmap/echarts 等块渲染。", "同步生成每页 package schema：manifest、blocks、evidence、metrics、scenarios、rendered_html。" ], "tag": "结果协议", "name": "SQL Presentation Hub：交付物 SQL-to-HTML", "owner": "商务材料 / 客户演示 / 证据页面", "price": "交付协议", "manual": [ "每个客户演示单独写 HTML。", "页面格式、内容、证据和版本混在一起，难复用。", "结果无法被 SQL 查询、无法稳定版本化。" ], "people": "避免每个客户重写一套 HTML", "evidence": [ "现有页面包括 ruide-ai-project-v1、ruide-pcb-review-v1、ruide-reconciliation-huimao-v1。", "sph validate 显示现有页面包 contract_ok=true。", "本白皮书自身也以 SQL-to-HTML 页面方式交付。" ], "upstream": "业务证据、指标、规则、场景、页面块、渲染配置", "downstream": "公网 HTML、JSON API、页面包 schema、后续 PPT/报告/看板 renderer" }, { "ai": [ "平台变成 Agent 的受控数据后端，而不是只给人看的前端。", "通过 schema/table 级短期 token 暴露只读数据能力。", "Agent 通过 dw CLI 使用 token 拉数据，跳开裸数据库密码。" ], "tag": "权限边界", "name": "DataWeave Agent 化：受控数据出口", "owner": "企业数据后端 / Agent 数据消费", "price": "数据协议", "manual": [ "人复制连接配置，但不能安全暴露数据库密码。", "每次给 Agent 数据都要重新解释连接、schema、表和权限边界。", "大客户数据无法随意把 DB 凭证交给任务 Agent。" ], "people": "减少人工拷贝连接和重复授权", "evidence": [ "2026-06-09 已增加 data access token 迁移。", "会议中明确提出 24/48 小时或 7 天 schema/table 级只读 token。", "定位从“前端平台”转向“Agent 可消费的数据内核”。" ], "upstream": "数据库连接、schema、表、查询、权限、临时访问 token", "downstream": "dw CLI/API 给下一个 Agent 拉取数据" } ] } }, { "id": 5, "block_type": "scenario_grid", "title": "客户场景案例：先还原成数据，再让 Agent 接管", "subtitle": "判断一个场景能不能做，不取决于我懂不懂行业软件，而取决于它能不能被还原成结构化数据。", "props": { "scenarios": [ { "ai": [ "不从人用界面理解 PCB，而是把板、层、线、元件、坐标、测试点还原成数据。", "把 46 条审核标准投射到结构化规则和证据表。", "用 SQL-to-HTML 生成带坐标和违规点的评审工作台。" ], "tag": "结构化突破", "name": "PCB 工艺评审：绕开人用设计软件，接管底层数据", "owner": "瑞德智能 / 工程与品质", "price": "可立项客户场景", "manual": [ "人必须理解专用 CAD/PCB 软件和专有格式。", "评审依赖工程经验、规则散落、证据难复现。", "客户看到的是设计软件表层，Agent 难直接接管。" ], "people": "从专用软件依赖转为数据化审查", "evidence": [ "已生成 ruide-pcb-review-v1 页面。", "评审工作台中规则、结论、坐标和图形对象来自 SQL。", "客户侧已认为该方向具备立项可能。" ], "upstream": "PCB Doc/设计数据、坐标、走线、元件、测试点、审核规则", "downstream": "SQL 化评审证据、违规点坐标、可视化工艺评审页面" }, { "ai": [ "把客户 Excel 表头映射到 ODS 字段。", "用 SQL 表达对账数量、对账单价、对账金额和差异。", "自动生成带规则、字段映射、明细表和风险结论的页面。" ], "tag": "财务数据化", "name": "辉贸客户对账：从 ODS 到差异结论", "owner": "瑞德智能 / 财务与 IT", "price": "演示转交付样例", "manual": [ "财务人员手工理解 Excel 表头和业务规则。", "人工计算单价差、金额差和风险等级。", "对账结果难解释、难复算、难追溯。" ], "people": "减少人工 Excel 对账", "evidence": [ "已生成 ruide-reconciliation-huimao-v1 页面。", "样例中字段覆盖 31/31，中高风险 4 行，差异合计 842.90。", "页面不是死 HTML，而是由 ODS 映射、规则和样例行驱动。" ], "upstream": "ERP/ODS 销售明细、客户确认价、未开票数量、销货单号、品号", "downstream": "差异表、风险标记、对账规则、可下钻 HTML 页面" }, { "ai": [ "把每个场景统一表达为上游、下游、人工模式、AI 模式、证据和报价。", "把商务呈现转成 SQL Presentation Hub 页面包。", "让后续版本变成数据表 v1/v2/v3，而不是重做页面。" ], "tag": "商务交付", "name": "瑞德 AI 场景化立项：从数据治理到商务呈现", "owner": "瑞德智能 / 多部门", "price": "65 万元方案样例", "manual": [ "每个场景单独梳理材料、截图、PPT 和页面。", "报价、ROI、证据和实施路径分散维护。", "客户演示依赖一次性手工材料。" ], "people": "把分散需求变成可治理场景包", "evidence": [ "已生成 ruide-ai-project-v1 页面。", "六个场景、报价、ROI 和路线图均以同一结构表达。", "会议中明确提出“拿到数据就能出 demo”的管线目标。" ], "upstream": "BOM、环保资料、IQC、PCB、采购交期、财务对账等场景数据", "downstream": "场景证据、报价、ROI、路线图、客户演示页面" } ] } }, { "id": 6, "block_type": "echarts", "title": "架构图：企业 Agent 的四个平面", "subtitle": "不是做一个更复杂的工作台，而是重建 Agent 可消费的数据与命令平面。", "props": { "charts": [ { "note": "从人用系统到 Agent-first 系统：UI 从底座退为最后的 renderer。", "option": { "radar": { "indicator": [ { "max": 10, "name": "Agent 可消费" }, { "max": 10, "name": "可复现" }, { "max": 10, "name": "可审计" }, { "max": 10, "name": "权限边界" }, { "max": 10, "name": "交付复用" }, { "max": 10, "name": "UI 优先" } ] }, "legend": { "data": [ "传统 Human-First", "Agent-First Data Protocol" ] }, "series": [ { "data": [ { "name": "传统 Human-First", "value": [ 3, 4, 4, 5, 3, 9 ] }, { "name": "Agent-First Data Protocol", "value": [ 9, 9, 8, 8, 9, 4 ] } ], "type": "radar" } ], "tooltip": { "trigger": "axis" } } }, { "note": "四个平面对应四类协议：事实、动作、边界、结果。", "option": { "series": [ { "data": [ { "name": "企业 Agent 底层系统", "children": [ { "name": "SQL 事实平面", "children": [ { "name": "资产" }, { "name": "指标" }, { "name": "规则" }, { "name": "证据" } ] }, { "name": "Bash/CLI 行动平面", "children": [ { "name": "ctx" }, { "name": "dw" }, { "name": "sph" }, { "name": "脚本编排" } ] }, { "name": "Token 边界平面", "children": [ { "name": "schema 级" }, { "name": "table 级" }, { "name": "短期只读" }, { "name": "审计" } ] }, { "name": "Renderer 结果平面", "children": [ { "name": "HTML" }, { "name": "报告" }, { "name": "看板" }, { "name": "API" } ] } ] } ], "roam": true, "type": "tree", "label": { "align": "right", "position": "left", "verticalAlign": "middle" }, "leaves": { "label": { "align": "left", "position": "right", "verticalAlign": "middle" } }, "orient": "LR" } ], "tooltip": { "trigger": "item" } } } ] } }, { "id": 7, "block_type": "context", "title": "与入口型企业 Agent 的根本差异", "subtitle": "不是否定入口和协同，而是明确底座和入口不是同一层。", "props": { "after": [ "把 Agent 当成企业软件的新消费者，重建可消费底座。", "让人的工作台退到渲染和验收层。", "通过真实客户问题的穿透速度和交付转化率竞争。" ], "cards": [ { "items": [ "重点在 IM、办公入口、协同工作台、应用集成和人用流程。", "价值是降低人的使用门槛，适合覆盖大量员工和既有办公生态。", "风险是 Agent 仍然依赖散乱数据、弱权限边界和不可复现流程。", "容易把企业级误解为 UI 丰富、协同复杂、入口统一。" ], "title": "入口型 Agent" }, { "items": [ "重点在数据协议、命令协议、权限协议和交付协议。", "价值是让通用 Agent 稳定接管真实业务事实和业务动作。", "判断标准是能否把客户真实问题快速转成数据、规则、证据和结果。", "企业级不由 UI 定义，而由确定性、审计性、可复现性和权限边界定义。" ], "title": "底座型 Agent" } ], "before": [ "把 Agent 做成一个更会聊天、更会协同的工作台。", "在存量系统上增加 Agent，让 Agent 迁就人的操作路径。", "通过产品入口竞争。" ] } }, { "id": 8, "block_type": "roi", "title": "价值判断：为什么这条路能持续拿结果", "subtitle": "它把客户问题从“要不要懂行业软件”降维到“能不能结构化表达”。", "props": { "payback": "每个客户场景复用", "benefits": [ "场景选择更清晰：能数据化表达就接，纯感觉、强非确定性、无法结构化的场景少碰。", "交付路径更短：从数据治理直接到 SQL-to-HTML 页面，而不是每次重新做材料。", "Agent 使用更稳定：CTX 解决找上下文，DW 解决拿数据，sph 解决出结果。", "客户沟通更有穿透力：不必先成为行业软件专家，而是证明能把行业对象还原为数据并产生结果。", "长期资产可沉淀：每次交付都会增加资产、协议、模板、规则和案例，而不是只留下一个死页面。" ], "investment": "深耕 SQL/CLI/协议", "optimistic": "形成企业 Agent 底座", "conservative": "更快做出 Demo" } }, { "id": 9, "block_type": "roadmap", "title": "接下来 12 个月的深耕路线", "subtitle": "不要急着产品化 UI，先把 Agent 消费路径打穿、打稳、打可复用。", "props": { "phases": [ { "name": "Phase 1", "focus": "协议补全：让 Agent 少解释也能消费", "items": [ "为 CTX 增强概念词、同义词、会话摘要和任务意图召回。", "把 sph 页面协议继续稳定为可复用的页面包模型。", "把 DataWeave 的 schema/table 级短期 token 跑通最小可用闭环。" ] }, { "name": "Phase 2", "focus": "案例沉淀：每个客户场景都变成资产", "items": [ "把 PCB、对账、BOM、环保资料、采购交期等场景统一沉淀为模板。", "每个模板包含数据接入、规则、证据、交付页面和验收方式。", "建立 Agent 消费失败反馈机制，让 Codex/Claude 反向定义上游协议改进。" ] }, { "name": "Phase 3", "focus": "产品表达：从工具链升级为底座叙事", "items": [ "对外表达为 Agent-First Data Protocol / 数据协议优先的企业 Agent 底座。", "保留 UI 作为客户验收与演示层，不让 UI 主导底层设计。", "用真实客户案例证明：同样业务问题，谁能更快数据化、规则化、交付化。" ] } ] } } ], "evidence": [ { "slug": "agent-first-data-protocol-whitepaper-v1", "evidence_id": 1, "block_id": null, "evidence_key": null, "claim": "", "status": "draft", "source_type": "local_project", "source_ref": "/home/claw/asset-ods/README.md", "payload": {}, "created_at": null, "updated_at": "2026-06-11 08:08:16.916058+08:00" }, { "slug": "agent-first-data-protocol-whitepaper-v1", "evidence_id": 2, "block_id": null, "evidence_key": null, "claim": "", "status": "draft", "source_type": "local_project", "source_ref": "/home/claw/projects/sql-presentation-hub/README.md", "payload": {}, "created_at": null, "updated_at": "2026-06-11 08:08:16.916058+08:00" }, { "slug": "agent-first-data-protocol-whitepaper-v1", "evidence_id": 3, "block_id": null, "evidence_key": null, "claim": "", "status": "draft", "source_type": "meeting_transcript", "source_ref": "/home/claw/tmp/meeting_zou/20260609224633-马骋的快速会议-逐字稿文本-1.txt", "payload": {}, "created_at": null, "updated_at": "2026-06-11 08:08:16.916058+08:00" } ] }