🏠 home › journal › 2026-04-17

2026-04-17 变更日志

摄取 Sentino Memex 记忆框架

来源：raw/snippets/sentino-agent/memex-architecture.md（基于 /Users/momo/local/memovis/memex 源码梳理，忽略 embedding 部分——已构建未实际使用）

新建页面

关键知识提取

  1. 两套记忆设计哲学的对照轴 — Claude Code Auto Memory（LLM-in-the-loop，控流入，少而精）vs Sentino Memex（LLM-as-extractor，控保鲜，多而衰减）。这是本次摄取最大的交叉发现：两者不是优劣，是适配不同场景（单用户低频 vs 多用户高频 SaaS）的工程选择 → 在 auto-memory 中加入互相对照段落，建立完整双向链接

  2. Reinforce > Create 是 prompt-driven 的核心抗膨胀杠杆 — LLM 输出 ### Reinforce 段落列出要强化的 gist id，强化 = 重置 forgetAt 时钟。不是代码硬约束，靠 prompt 引导——意味着 prompt 质量直接决定记忆膨胀速度 → 与 Auto Memory 的"feedback 不只存负反馈也存正反馈"逻辑同源——都是用"加强已有"对抗"重复创建"

  3. embedding 已建未用是关键观察 — 1024-dim vector 列在 Event/Gist 都建了，但生产路径绕过它。<500 active gists 时全量返回 profile + gist 拼成纯文本。vector 是兜底而非主路径——这印证了 Harness Engineering "记忆选 Markdown 而非向量数据库"在不同形态下的同一判断 → 重要工程教训：vector retrieval 在中等规模（<千级）下不一定有性价比，全量返回 + LLM 自筛可能更简单可靠

  4. Prompt 统一中文是 Cache 经济学的应用 — 原本 zh/en/ja/ko 四套 prompt 完全击穿 LLM provider 的 prompt cache。统一为单个中文 prompt 后单 cache 跨所有用户共享。这是 harness-engineering "Cache 经济学是架构约束"原则的具体落地案例

  5. Sentino 选 Memex 模式的产品论证 — 与 sentino 的"AI 陪伴+记忆是核心资产"匹配。AI 语音陪伴是高频、多用户、记忆是核心资产而非 Agent 的辅助——这种场景必须用服务化 + 流水线提取，不能用 Claude Code 的 LLM-in-the-loop 模式

更新页面

待办

补充：Sentino Memex 对外定位锚点

触发：客户对话需要差异化 Memex vs mem0，需要长期复用的战略锚点

锚点表述

Sentino 走文本结构化记忆 + 大模型自判路线，与 Anthropic Claude Code 同方向，与 mem0 等向量检索方案是不同代际的判断。

论证三段式

  1. 行业转向已发生：2022–2023 主流是向量检索（mem0 路线），2025–2026 业界共识转向"让模型读全集自判"——上下文窗口扩大 + 推理成本下降使其可行
  2. 向量检索的固有问题：会拉错（语义相似 ≠ 语义相同）/ 不可审计 / 不可编辑 / 不可预期
  3. Anthropic 同款判断作为最高背书：Claude Code 明确选 Markdown + 索引而非向量数据库——透明可编辑、原生 Git、与文件系统集成。Anthropic 这么选 + Sentino 这么选 = 同一个判断

适用边界（必须同时讲，避免过度承诺）

通用 Agent 记忆基础设施场景，mem0 仍是合理选择（生态/多 vector backend/开源）。Sentino 专注"记忆质量直接决定用户留存"的关系型 AI 产品，不在通用赛道与 mem0 竞争。

更新页面

重要观察

这条锚点的力度来自第三方背书 + 行业时机，不是 Sentino 自吹。任何对客户讲 Memex 的场合都应该把 Anthropic 同路线这一点放在前面——比讲自家三段流水线、4 级 TTL 都更有说服力。

摄取 Claude Code 记忆系统（s09 章节）

来源：raw/notes/claude-code-memory-system-s09-2026.md（Claude Code 源码深入探索系列 / s09 记忆系统、系统加固，414 LOC, 5 个工具）

新建页面

关键知识提取

  1. 反向定义比正向定义更重要 — memory 不是"更长一点的上下文窗口"，立"什么不该存"的边界（文件结构/任务进度/分支名/代码细节/密钥）才能避免系统从"长期变聪明"退化为"长期产生幻觉" → 与 llm-wiki-pattern 的 raw/wiki 分层同构：什么是不可变素材 vs 什么是编译后的知识

  2. Auto Memory 与 Auto Dream 的分工 — Auto Memory 管"流入"（写入边界），Auto Dream 管"保鲜"（整合修剪）。两者构成完整的记忆生命周期，任一失守系统都会腐烂 → 已在 concepts/auto-dream 中加入"与 Auto Memory 的分工"段落，双向链接闭合

  3. feedback 不只来自负反馈 — 只存纠错的系统会越来越保守却不一定越来越聪明，必须同时保存被验证有效的正反馈（不明显的做法被用户认可） → 这是与"知识复利"概念的隐性连接：纠错 + 正反馈一起，才是真正的复利

  4. memory 会漂移 — memory 记录"曾经成立过的事实"，不是永久真理。冲突时优先相信当前观察。推荐具体路径/函数/外部资源前要再验证一次 → 与 agent-runtime-architecture 的 Layer 3 prefetchMemoryAndSkills 对应：memory 是预取的方向提示，不是替代当前 Read/Grep 的答案

  5. memory / task / plan / CLAUDE.md 边界四分 — 时效维度划分：当次任务（task/plan）vs 跨会话（memory）vs 长期项目级（CLAUDE.md）。这是给个人知识管理（obs-wiki）的镜像启发——raw/wiki/journal 也是同构的时效分层

更新页面

待办

补充：Claude Code 记忆机制运行时实证

来源：raw/notes/claude-code-memory-session-evidence-2026.md（从 ~/local/claude-code/session.json 抽样的真实 session 行为）

为 s09 教学章节补充运行时第一手证据，所有教学描述都已被实证或修正。

关键实证发现

  1. 存储路径项目级隔离：~/.claude/projects/<encoded-cwd>/memory/，cwd 用 - 替换 / 编码进路径——切换 cwd 就切换记忆库
  2. frontmatter 多一个 originSessionId 字段：教学版没有，实际版每条 memory 都可追溯创建来源
  3. "memory 会漂移"是 runtime 强制提醒：读 3 天前的 memory 时自动注入 <system-reminder>This memory is 3 days old...Verify against current code before asserting as fact.</system-reminder> —— s09 第 4 条边界不是建议，是有机制实现的
  4. 写入工作流实证：Read 相关已有 memory → 不存在才 Write 新文件 → Edit MEMORY.md 索引（不是 append 末尾）。"不写重复 memory"原则有具体执行路径
  5. memory 走普通文件系统机制：被 file-history-snapshot 跟踪，与源代码共享版本/回滚——印证 Harness Engineering "记忆选 Markdown 不选向量数据库"的架构理由
  6. 作用域分层未实现：s09 提到的 private/team 分层，当前 Claude Code 全部是 cwd 级 private；这是教学版超前于实现的一项
  7. Why / How to apply 结构在实战中真在用：project_sentino_terminal_facing.md 完整使用，不是装饰

更新页面

待办

摄取 Sentino × TENGA 合作机会评估

来源： - raw/notes/tenga-group-discussion-2026.md（Sentino 内部群聊原文，Chris/CEO + 子昕/产品 + 姜涛/技术） - raw/notes/tenga-research-2026.md（subagent 深度调研，覆盖公司本质/品牌动作/数字化布局/海外战略/竞品对照/决策层/品牌底线七维度）

新建页面

关键知识提取

  1. 市场窗口：主流 LLM 集体退场 — 2026 年 3 月 OpenAI Adult Mode 无限期搁置（员工反对+加州 16 岁少年情感依赖案件）；Claude/Gemini 全拒。全球没有任何主流 AI 能严肃回答性健康问题——这是窗口期 → 连接：与 individual-vs-institutional-ai 直接相关——严肃性健康 AI 必须是机构级（医生审核 + 合规 + 数据治理），主流个体级 LLM 因合规风险主动退场

  2. Seicil 是被低估的核心资产 — TENGA HEALTHCARE 子公司 2019 年上线的青少年性教育 Q&A 网站，年 PV 200 万+，由匿名医生人工回答。三个瓶颈：响应慢（异步）、不可扩展（仅日语）、无个人化。AI 化是把日语圈社会资产变成全球品牌护城河的最低成本路径 → 连接：与 ip-economics 同构——TENGA 的资产不在产品本身，在"去污名化"叙事+医学合作+教育内容这套软资产，AI 是杠杆放大器

  3. TENGA 与 Lovense 的反向定位 — Lovense 2025-11 推 AI Companion（AI 女友+接管 toy 控制），已吃过两次隐私丑闻；TENGA 公开声明产品不替代女性身体，刻意去色情化。两条路根本对立——TENGA 要的是主流文化承认（被 Good Design Award 出局时松本公开抗议为证），不要 niche 灰色地带 → 连接：与 parasocial-monetization 形成对比——Lovense 走 OnlyFans 式拟社交变现，TENGA 走的是"性教育基础设施"路径，是同一市场的两种截然不同变现模式

  4. 2026-02-13 数据泄露让"AI + 隐私"成为合作公关话术 — TENGA Store USA 邮箱被钓鱼攻击窃取，公司事后启用 MFA。性健康对话比邮箱敏感 100 倍——Sentino 的 IoT/Agent 平台天然支持本地化部署、终端直连、零知识匿名 ID，这是当下最能打动决策层的技术答案 → 连接：与 Sentino 的 IoT 终端直调架构（见 sentino-iot）逻辑一致——隐私优先不是事后补丁，是架构选择

  5. CEO 约束 vs 团队建议的对照 — 群聊中三种立场（子昕硬件方案被否、Chris 虚拟偶像 OnlyFans 路线与 TENGA 品牌冲突、姜涛性健康顾问机器人）。只有姜涛的方向同时满足 CEO 三约束（纯软件/快/易拿预算）+ TENGA 品牌底线（去污名化/医学/教育） → 元教训：CEO 的"建议"实际是约束（已存入 project_sentino_team.md），但 CEO 个人偏好的方案（虚拟偶像）未必符合客户品牌底线，需要用客户调研事实反驳

更新页面

待办事项

摄取 YUKAI × Agora 陪伴机器人 AI Agent PoC PRD

来源：raw/notes/yukai-agora-poc-prd-2026-04-14.md（PRD 草稿，2026-04-14，机密；文档所有者 Donnie / 开发负责人 Agora 即 sentino-agent / 客户 YUKAI Engineering / 目标 2026-06 底交付）

新建页面

⚠️ 摄取首版判断错位（同日修订）

首版误判：把 PRD AC-08 "记忆 (mem0)" 当成"客户已选型 mem0，Sentino 必须接入第三方"，写出整套"首次不使用 Memex 的客户项目"叙事。

正确判断：PRD 中 mem0 是能力代名词——mem0 在 2024-2026 年成为"AI Agent 记忆"行业事实参照系（类比 Twilio 之于电话、Stripe 之于支付）。客户用 mem0 一词描述能力需求，不等于客户做过技术选型评估。Sentino 实际交付方案是 sentino-memex，配套销售材料 ~/local/claude-code/sentino-memex-positioning.md（中英文版，已 push 到 iot-docs/sentino/）就是给本客户准备的"我方 vs mem0"对比教育材料。

修订动作：已回滚 sentino-memex 的"何时不使用 Memex 合理"补丁；删除 sentino-agent 经验教训中"客户预先选定的记忆方案不是技术评估问题"一条；改写 mem0 概念页对 yukai-agora-poc 关系段；其他 5 个页面相关描述全部修正。

留下的真教训 → 已存为 memory feedback_prd_capability_proxy.md：客户文档里出现第三方技术名（mem0/Pinecone/Twilio/...）通常是能力代名词不是技术选型；摄取 PRD 时先问用户是哪种再下笔，尤其当用户已对该客户做过 pitch 销售材料时。

关键知识提取（修订版）

  1. PRD 中第三方技术名通常是能力代名词 — mem0 在 2024-2026 是"AI Agent 记忆能力"事实参照系。客户 PRD 写"AC-08 mem0"不是技术选型决定，是借用代名词描述能力需求。Sentino 销售姿态：主动承担术语切换教育，不让客户做技术选型功课 → 与 sentino-memex "对外定位锚点"形成销售执行路径——Memex 概念页讲"为什么 Sentino 选 Memex 优于 mem0"，本案例是这套话术的首次对外实战；配套 sentino-memex-positioning 中英文销售材料已就绪并 push 到 iot-docs

  2. mem0 ADD-only 架构是官方明确承认而非外部攻击 — 2026-04 官方博客《Token-Efficient Memory Algorithm》明确说该架构在 multi-session reasoning / temporal reasoning / event ordering 上是弱项；官方《State of AI Agent Memory 2026》自承 staleness detection 是该领域 4 大未解问题之一 → 这是给客户讲 Memex vs mem0 对比的最有力背书——不是 Sentino 单方面攻击，是 mem0 自承事实。已纳入 mem0 概念页核心机制段落，Memex 销售材料引用此事实

  3. YUKAI 的"低 AI 高情感"路线与硅谷"高 AI 弱拟物"路线第一次具体对接 — Qoobo 不说话因为说话破坏情感投射；Mirumi 只看你点头；fufuly 只是呼吸。这条路线与 ip-economics "留白原则"完全同构。YUKAI PoC 是第一次把"AI 加满"装进"减少表达"哲学的产品形态 → 与 voice-ai-companion-market 设备赛道补充日本细分支：Sony aibo / Lovot / YUKAI 三家代表"低 AI 高情感"路线，与 Friend / Omi / Gumdrop 的"高 AI 弱拟物"并列。潜在产品哲学冲突——把 LLM 装进 Qoobo 模式可能反而破坏关系，PoC 通过不代表产品对位

  4. PRD 反复强调操作员管理后台暴露 PoC 形态本质 — PRD 9 项验收标准里有 5 项（AC-01 后台 / AC-05 聊天记录 / AC-08 mem0 审查 / AC-09 UI / OI-08 日语本地化 QA）涉及操作员侧或后台。这说明客户买的是"有人在后台调 prompt 和审日志的辅助工具"，不是"端到端自动驾驶 AI" → 与 individual-vs-institutional-ai 的 deterministic vs nondeterministic 二分对应——PoC 阶段呈现的是 deterministic agent（操作员可控可审），上线后才考虑 nondeterministic。客户买的是可控性，不是惊喜

  5. 三模式（Normal/Sleep/Lazy）= 硬件状态空间必须前置定型 — Lazy 模式需软硬件共同设计，硬件接口未定就无法定稿。这印证 agent-runtime-architecture Layer 1（"先定义执行边界，再发起第一轮推理"）——硬件可达的状态空间必须在第一轮推理前定型，否则 LLM 不知道自己能不能"懒" → 与 agent-runtime-architecture 的 Layer 1 "执行边界定型"原则首次在玩具/陪伴机器人场景验证。机器人产品的 mode 不是 prompt 切换，是物理状态空间约束

  6. TTS 唱歌是 P0 验收 + P0 待评估的并存项 — AC-04 是必交付、OI-02 是"待 Agora 评估"。这是商业承诺与技术不确定性并存的项目典型形态。Sentino 现有 TTS 栈（Minimax / ElevenLabs / Qwen3）擅长说话不擅长唱歌，专门唱歌模型（Suno/Udio）又难做"指定角色音色" → 与 voice-presence 的 Sesame CSM 研究形成补丁——CSM 解的是说话的临场感，唱歌临场感是另一回事；行业目前没有"音色一致 + 自然唱歌"的成熟方案，本 PoC 极可能要降级为"念歌词"或固定音频回放

更新页面

待办

摄取 Hotmind 客户外接需求规范（角色翻转后重写）

来源：raw/notes/hotmind-family-agent-spec-2026-04-17.md（客户 Hotmind 写给"被招标 LLM 推理服务方"的对外需求文档，由客户/中间人直接拿来给 Sentino 参考——不是 Sentino 给客户的规格书）

重要纠正：第一轮把"我方"误解为 Sentino，所有"Sentino 平台对外开放工具"判断都是反的。本次重写视角：客户 = Hotmind（出硬件 + 出 MCP/REST 工具 + 出通知通道）；Sentino = 用完整 Agent 方案适配客户接口的承包方。原 concepts/family-iot-agent-spec.md 已删除（别人定的接口约束不构成 Sentino 自家方法论），原 projects/hotmind-family-agent.md 已重命名为 projects/hotmind-client.md 并按客户机会视角重写。

新建页面

关键知识提取

  1. 客户与 Sentino 的边界划在哪一层是销售形态的核心变量 — yukai-agora-poc 是"客户出硬件 + IP，Sentino 出全栈 Agent 平台"；Hotmind 是"客户出硬件 + 平台数据 + 工具 + 通知通道，Sentino 只出 LLM 推理 + Agent 工程"。两个客户对 Sentino 是不同形态的能力检验——YUKAI 检验全栈架构能力，Hotmind 检验在被定义清楚的窄槽位里 prompt + 工程深度 → 与 sentino-agent 的客户矩阵直接相关——Sentino Agent 平台不能只按一种形态报价/交付，需要分清"全栈白标 vs OpenAI 兼容端点 vs MCP-tool 接入"等不同切入形态

  2. 客户 RFP 假设承包方是"LLM 推理服务方"，Sentino 实际是 Agent 方案——文档与现实不对称是销售机会 — 客户文档按"被招标 LLM 推理供应商"形态写接口约束，竞品大概率是按 token / 调用计费的纯模型 API 包装方。Sentino 的差异化必须主动重新定义双方边界——"我们不只是 LLM 推理，是完整 Agent 工程" → 与 yukai-agora-poc AC-08 "PRD 写 mem0 是行业代名词，Sentino 用 Memex 交付" 的术语切换教育同源——客户文档术语是参考系，承包方要主动承担术语切换教育，避免被困在客户原本的报价模型里

  3. MCP 在 B2B 集成 server/client 端演进非对称 — 客户已经把 MCP server 作为 RFP 标准接口（一年前还需要自己设计 function calling），但Sentino 当前不使用 MCP，走传统 HTTP-as-tool 方案——把客户 REST API 包装成 LLM function calling 工具集。客户主动留 REST 兜底正是因为承包方 Agent 框架不一定 MCP-aware → 与 mcp-protocol 在企业落地的真实形态印证：MCP 的 server 端（数据/工具持有方）演进比 client 端（Agent 框架方）快——客户为了不赌承包方一定会用 MCP，主动出双形态接口。Sentino 是否引入 MCP client 工程能力（自建 vs 复用 claude-agent-sdk）是开放问题，等到第二/第三个开放 MCP server 的客户出现再立项也来得及

  4. 反向通知 + cancel_action 是客户做得好的设计，值得 Sentino 反向学习 — 客户的 agent_action_result 通知里有 cancel_action 字段（仅 action=created 时提供，让设备渲染"撤销"按钮），构成 Agent → 环境（执行） + 环境 → 用户（通知） + 用户 → Agent（撤销） 的三段闭环 → 与 agent-tool-design 通常讨论的"工具是 Agent → 环境单向"不同。Sentino 自家 Standalone Agent 工具协议没有这种"操作回执 + 撤销路径"机制——把客户这套设计反向学习进 Sentino Agent 平台，可以提升未来对其他客户做品牌白标时的产品完成度

  5. 客户主动放弃声纹消歧是反直觉的可靠工程选择 — "帮小明设个闹钟"中的"小明"由 Agent 通过对话 + 档案匹配，不靠声纹。理由：声纹不稳定 / 隐私敏感 / 老人小孩声纹易错 → 工程哲学："复杂底层方案（声纹）不一定比简单上层方案（对话匹配）更可靠"。值得 Sentino 在自家家庭/陪伴产品中重复验证——这条与 first-principles-deletion "有必要吗 / 必须这样吗" 同源

  6. 客户接口规范的细致程度反过来约束 Sentino 自由度，但也降低验收风险 — summary 国际化 / 危险操作 agency 边界 / 多用户消歧策略 / 时区处理 / 工具参数英文 / OpenAI body 自定义字段——客户已预先定死，Sentino 在 prompt 工程层之外没有架构发挥空间 → 接窄不一定是坏事——意味着客户对结果质量的判定标准也清晰，PoC 验收风险低；但 Sentino 报价不能按客户假设的 "LLM 推理供应商" 模型走，要争取 PoC + 包月 / 人月模式

  7. OpenAI 兼容 streaming endpoint 是 Sentino Agent 平台需要新增的对外形态 — Sentino Agent 平台之前对外接口形态多样（直接 SDK / Agora ConvoAI 直连 / 自家 IoT 协议），第一次需要包一层 OpenAI 兼容 streaming endpoint，把 workflow-engine 的输出适配成 OpenAI SSE → 与 agora-convoai-server 的 llm_config.url 标准模式相关——这是"被采购的 LLM 推理服务"形态的事实约定。一旦 Sentino Agent 平台做好这层，对未来其他客户都可复用——是 Sentino 平台的新工程能力点

更新页面

删除页面

待办

摄取腾讯研究院《Vibe Coding 没有颠覆游戏》

来源：raw/notes/huxuan-vibe-coding-games-2026.md（腾讯研究院公众号 2026"长文的春天"征文，作者胡璇高级研究员；非 Sentino 客户文档，纯行业分析）

新建页面

关键知识提取

  1. vibe coding 平台缺 Layer 4-6 = 普通用户 6% 完成率 — 一线开发者反映"AI 写单个系统很强，但多系统串联协同时顾此失彼"+ "80% 时间在 debug" + AI 游戏开发平台只有 6% 用户能提交完整作品。这不是模型能力问题，是缺少 Tool Runtime / Permission / Task System 三层运行时抽象——专业团队（CREAO）有架构师补齐，所以能跑出 99% AI 代码 vs 普通用户 6% 完成率 → 与 agent-runtime-architecture 七层模型 Layer 4-6 直接对应：原本是源码侧验证，现在是消费侧反向实证，七层模型多了一组"缺哪层就有什么症状"的诊断表 → 与 harness-engineering 增加推论：Harness 能力的有无决定 AI 创作能力的杠杆倍数

  2. "L = Language" 边界在 vibe coding 一线被反复印证 — 跨系统协同 = 全局结构化状态保持，正是 LLM 弱区；bug 隐式定位 = 多步因果回溯，仍需工程经验；"AI 是超强副驾驶，但方向盘还是得你自己握" 是开发者直接表达 → 与 individual-vs-institutional-ai "L = Language" 论点同源同向：原本是 CIO 视角，现在是开发者视角，两个视角合流证明 Language 任务和结构化协同任务的边界不是模型能力增强能消除的——是任务类型的本质边界

  3. "AI 生成血肉，人的判断是灵魂" = 审美护城河在游戏媒介的具体表达 — 三类创作者动机访谈给 aesthetics-beyond-visual "审美 = 经历 = 不可复制" 论点提供第三组直接引言级证据（前两组是宫崎骏案例和 _why 论点）：判断哪些重要、什么是好想法、情感是否真诚 — 三个维度都是 AI 给不了的 → 与 experience-over-knowledge 同源同向加深："AI 让知识贬值、经验升值" 在创作领域有了游戏开发者的杠杆数据——"摩天大楼 vs 扫雷"取决于经验，AI 不是替代经验，是把经验积累的速度加快 10 倍

  4. 品味社区是 vibe coding 时代分发链的关键基础设施 — Steam 让长尾游戏活下来不是推荐算法，是评测/鉴赏家/标签/讨论区四件基础设施。当 vibe coding 把内容生产成本压到接近零，分发瓶颈从"曝光"切换到"鉴别"，鉴别的基础设施是社区不是算法。国内贴吧衰落 + TapTap 仅以产品为单位做社群 = 缺失基建，供给爆发后大概率滑向流量买量逻辑 → 与 parasocial-monetization 互为反面（拟社交假装关系 vs 品味社区真实判断），与 content-hook-model 互补（单条内容的内部钩子 vs 跨内容的横向信任结构）

  5. "封面欺诈"是信任崩塌在 vibe coding 分发链的新形态 — Rosebud 上"AI 生图封面精美 + 实际游戏接近扫雷"是新型作品质量造假。机制差别：传统 chatter / 软文是平台维护成本，可规则约束；封面欺诈是 AI 工具能力错位副产品（生图远超生游戏），没有规则能彻底防住——AI 越强生图，与实际游戏内容落差就越大 → 在 parasocial-monetization 信任崩塌矩阵新增第三类：作品质量造假；解法只能靠品味社区（taste-community curator/评测的强信号对抗）

  6. PDF2GAME 与 LLM Wiki 是同源结构化提取模式 — PDF2GAME 流水线"上传图书 → 大模型提取全文 → 结构化为人物/地点/事件实体 → 衍生互动游戏"，本质与本知识库 raw → wiki 编译同构——非结构化文本到结构化中间层到应用，应用方向不同（互动叙事 vs 知识查询），中间层模式相同 → 在 llm-wiki-pattern 加入同源案例段落，验证"raw → 结构化中间层 → 应用"是 LLM 时代处理非结构化文本的通用范式

  7. PixelHQ 类工作可视化陪伴 = AI Companion 第三形态 — 把 Claude Code 工作过程映射为像素办公室人物动画，不增加任何 AI 智能，纯把已有 AI 工作过程"情感化呈现"。这与 YUKAI 低 AI 高情感路线哲学一致，只是介质从硬件变成屏幕 → 在 voice-ai-companion-market 新增第三类形态（屏幕内+工作可视化），与硬件高 AI 弱拟物 / 硬件低 AI 高情感并列；对 Sentino 启示：实体玩偶 + 配套 App 显示玩偶在"做什么" = 被陪伴的连续感

  8. 公共版权 IP 是留白原则的另一面 — Rosebud 上《呼啸山庄》案例典型，三重优势（公版无授权 + 原作素质极高可喂 AI + AI 擅长降本网状剧本）。形象 IP 留白靠"不画嘴/不开口"，公共版权 IP 留白靠"经典文本本身就是开放解读" → 在 ip-economics 加入"公共版权 IP" 作为另一种留白模式；对 Sentino 启示：除商业 IP 授权（Jisoo Shumon），公共版权 IP 可作为低成本起步路径验证 AI 人格设计

  9. 平台审核反向制约 vibe coding 平台坍缩 — App Store 以"绕过审核机制的动态代码执行"下架多个 vibe coding 工具 iOS 版；2025-12 提交量同比 +56% 审核排队拉长到数周；微信小程序备案 5-10 工作日 + 个体工商户。模型厂商可以吃掉中间层，但分发平台是最终的层级守门员 → 在 platform-layer-collapse 加入反向论点：层级坍缩在中间层快、在分发层短期不会；vibe coding 出口瓶颈正从代码生成能力转移到上架合规

更新页面

事实核查记录

声明 核查方法 结论
巨鸟多多工作室 / Dota Auto Chess / 2019-01-04 / Steam Workshop WebSearch（Wikipedia / GamesRadar / ModDB / NamuWiki 多源） 全部属实，Drodo Studio 5 人小团队，2019-01 Steam Workshop 发布，几个月 800 万订阅 30 万 DAU
Rosebud 平台真实存在 + "200 万款游戏" WebSearch 平台真实（2019 Lisha Li 创办于 SF, 2024 末 $25M A 轮），具体游戏数字未独立核实，按原文转引保留并标注
PixelHQ @Waynedevvv 像素办公室 WebSearch 真实存在（GitHub waynedev9598/PixelHQ-bridge + iOS App Store + app.pixelhq.org，本地 WebSocket + 隐私优先架构）
"港大的 AI 角色小镇游戏 Ailization" WebSearch 错误——实际是 HKUST（港科大，不是港大 HKU）+ 项目名 Aivilization（不是 Ailization）。Prof. Chen Kani 团队 + Bauhinia AI 商业化，100,000 agents，每 agent $2/月。已在 raw 中如实记录原文 + 校正注，wiki 中不引用错误信息
9 个大模型决赛 Gemini 3.1 Pro 夺冠（开局蜀吴打魏的历史刻板印象） WebSearch 未查到独立公开来源，按原文记录但 wiki 摘录时未引用具体名次（避免传播未验证细节）

待办

摄取 Agora Conversational AI Engine v2 join API 官方文档

来源：raw/notes/agora-conversational-ai-join-api-2026-04-15.md（Agora 官方 REST API 参考 https://docs.agora.io/en/conversational-ai/rest-api/agent/join，文档导出 2026-04-15；事实核查通过 WebFetch 比对官方页面字段一次）

新建页面

关键知识提取

  1. mcp_servers 是 llm 对象内一等字段——MCP 已渗透到语音平台基础设施层（Layer 3） — 不只"客户开放 server / 乙方不一定 client"（Layer 1+2，已在 mcp-protocol 记录），更深一层是语音平台厂商作为 MCP client 把 MCP 内置进基础设施。开发者声明 server endpoint 即可，根本不需要写 client 代码 → 与 mcp-protocol 渗透三层模型直接连接：补充 Layer 3 实证；与 hotmind-client 强连接——客户开放了 MCP server 又用 Agora ConvoAI 编排，Agora 完全可以直接调客户 MCP 绕过 Sentino LLM

  2. 客户最终选 Sentino 而不是"Agora 直接吃客户 MCP"捷径——这是 Sentino 差异化护城河被强化定位的关键事实 — 工具中转能力 Agora 已经能干（mcp_servers），客户买 Sentino 是为 Agent 工程能力（多意图拆分/家庭成员消歧/危险操作护栏/prompt 调优/4 语种一致性）。这条事实把 Sentino 差异化护城河精确钉在 Agent 工程层而非工具中转层 → 与 sentino-agent 经验教训"客户 RFP 假设 LLM 推理服务方 vs Sentino 实际 Agent 方案"同源同向加深；销售姿态强化点已落到 hotmind-client 项目页

  3. Agora 显式建议迁移 turn_detection 旧版到新版 SoS/EoS 拆分 — 旧版 type=agora_vad/server_vad/semantic_vad + interrupt_mode 已 deprecated；新版 mode=default + config.start_of_speech + config.end_of_speech 各自配 vad/keywords/disabled/semantic 子模式。文档原文："To create more natural conversations and reduce unintended interruptions, Agora recommends using the latest version" → 与 agora-convoai-server 现存 ASR audio_vad 配置（interrupt_duration_ms: 160 / prefix_padding_ms: 800 / silence_duration_ms: 480 / threshold: 0.5）直接相关——这套参数属于旧版 deprecated 字段族，已在该页加入迁移建议；属于"Sentino 应主动评估迁移"的开放工程项

  4. semantic EoS 是 voice presence "对话动态"维度的工程化具体实现 — 旧版 VAD-only EoS 会把"我想想……"按静音长度误判为说完，semantic EoS 用语义模型判断意图是否完整，规避中断思考的失败模式。新版把 SoS/EoS 拆开让 semantic 只用于 EoS 端，是更工程化的设计 → 与 voice-presence "对话动态"四要素直接连接：补充第一个明确工程化样本；与 seal-architecture 感知层延迟问题同源

  5. Agora 平台层提供完整 SAL 声纹能力（locking + recognition），客户主动放弃 — Hotmind 家庭多用户场景明确选不用声纹，靠对话语义匹配 + 家庭成员档案做消歧。理由是声纹不稳定/隐私敏感/老人小孩声纹易错——这是"硬件/平台能力 ≠ 产品最优选"的反直觉但更可靠的工程选择 → 与 hotmind-client "客户主动放弃声纹消歧是反直觉的可靠工程选择"洞察的强化对照样本（已加入 hotmind-client 第 3 节）；与 first-principles-deletion "复杂底层方案不一定比简单上层方案更可靠"同源

  6. Sentino 走"半自定义模式"而非 cascade，标准接入参数固定：llm.vendor=custom + llm.style=openai + llm.url=https://api.sentino.jp/v1/agent/chat + llm.output_modalities=["text","audio"]；不配 tts.*（TTS 在 Sentino endpoint 内部 Minimax/ElevenLabs/Qwen3 选型）；不配 llm.mcp_servers（工具调度在 Sentino endpoint 内部走 REST + function calling）。调用代码参考 sentino-convo-ai 仓库 → 这是 yukai-agora-poc 与 hotmind-client 共用的接入配置；与 sentino-agent 经验教训新增条目对应；接入参数收敛 = 工程复用点，未来其他 Agora-接入客户都可复用。关键纠正：之前 subagent 第一轮把 Sentino 模式归到 cascade（ASR+LLM+TTS 三段）是错的——Sentino 是把 TTS 和 tool 都收到 endpoint 内部，对 Agora 来说就是"会出音频的 LLM"

  7. MLLM 端到端模式（OpenAI Realtime / Gemini Live / VertexAI）作为 Sentino 未来形态切换记录 — 端到端音频模型在副语言/turn-taking/音色一致性上理论有上限优势，但绕过 ASR/LLM/TTS 拆分意味着 Sentino 当前"半自定义 + workflow/tool 内部调度"的 Agent 工程优势不直接迁移。何时切是开放评估点 → 与 voice-presence 第二条工程路径连接（CSM 是模型方法，MLLM 是商业产品形态）；与 yukai-agora-poc "熊角色音色"目标关联——MLLM 在角色音色一致性上可能更适合

  8. filler_words / silence_config / farewell_config / graceful_enabled 等是生产级语音 Agent 的细节工程能力 — Sentino 自家是否实现这些是开放问题，已写入待办清单；与 voice presence 工程化进一步细分相关

更新页面

待办

补充：Sentino 接入模式纠正（cascade → 半自定义） + URL/Agora 字段使用纠正

触发：用户两次纠正——(1) Sentino 不是 cascade 模式，是半自定义模式；(2) URL 不是 /v1/chat/completions 而是 /v1/agent/chat，且 Agora 的 tts.* 与 mcp_servers 都不需要配置。

修正范围： - concepts/agora-convoai-join-api — 三种交互范式表扩展为四种（加入"半自定义"行 + 工程动机段）；LLM 配置层补 output_modalities 三种取值边界表 + 不配 tts/mcp_servers 明示；Sentino 视角速查表补 tts.*/output_modalities/mcp_servers 行；与三客户对应段落改写；接口文档参考段加中文版声网链接 + sentino-convo-ai 仓库引用 - concepts/agora-convoai-server — 云端 v2 join API 概览段从"三模式"改为"四模式"+ Sentino 半自定义模式说明；config.json 表的 tts.* 行加"Sentino 客户场景不用此字段"批注 - projects/hotmind-client — 接口约束 1 补 output_modalities=["text","audio"] + 关键说明；客户已做的部分把 "ASR + TTS + VAD 已配" 改为 "ASR + VAD 已配（TTS 由 Sentino 直出 audio 替代）" + 合作澄清提示；1b 段把"纯文本推理"改正为"纯推理"；与 YUKAI 对照表两行补 audio 流式 + Sentino TTS；架构图改写（Agora 不调 TTS，Sentino 直出 audio） - projects/yukai-agora-poc — 架构归属"Agora 接入形态"段从 cascade 改为半自定义；TTS 唱歌评估 落到 Sentino 内部 TTS vendor（不是 Agora tts.vendor） - projects/sentino-agent — 经验教训段 vendor=custom 那条全面重写：URL /v1/agent/chat + output_modalities + 不配 tts/mcp_servers + sentino-convo-ai 仓库引用 + 差异化护城河强化为"workflow + tool + text/audio 流式同步在一处统一控制"

关键纠正记录（防再错）： - Sentino 模式 = 半自定义（不是 cascade，不是 MLLM 端到端） - Sentino LLM URL = https://api.sentino.jp/v1/agent/chat（不是 /v1/chat/completions） - Agora 配置：tts.* 不配 + llm.mcp_servers 不配 + llm.output_modalities=["text","audio"] 必配 - 调用代码参考：Sentino 内部 sentino-convo-ai 仓库

三轮补充：Agora Agent Studio + pipeline_id（海外独有）

触发：用户对照 docs.agora.io 海外版与 doc.shengwang.cn 国内版后指出——海外版有 Agent Studio + pipeline_id 参数（先在 Web UI 配 ASR/LLM/TTS/turn_detection 并 publish，拿到 ID 后 join API 直接引用，properties 字段按字段级覆盖），国内声网版未暴露此参数。

新增内容： - concepts/agora-convoai-join-api — 新增"Agent Studio + pipeline_id（海外版独有，国内声网版未见）"完整段落（含示例 + 字段优先级 + 国内/海外功能差异 + Sentino 视角对 yukai-agora-poc hot-reload 后台需求的含义） - projects/yukai-agora-poc — 待办新增"评估 Agora Studio 是否能替代部分 hot-reload prompt 需求"——如果 Studio 能覆盖 ≥50% 操作员调 prompt 场景，PoC 工程量可显著收窄

关键洞察： 1. 国内 vs 海外功能差异是个独立模式——同一接口，海外提供低代码 Web UI 工作流，国内仍是"每次填完整 JSON"。这解释了为什么 yukai-agora-poc 客户提"操作员管理后台 + hot-reload prompt" 在国内是必需品（Studio 不可用）但在海外可能部分由 Studio 承接 2. Sentino 自家管理后台的产品定位需要分场景：国内客户场景下是必需品（Agora 不提供），海外客户场景下是"超出 Studio"的 Plus 能力（多客户隔离/角色权限/prompt 版本管理）。两种场景定位是否要分开是开放问题

四轮纠正：Sentino-Agora 竞合关系定位 + R1 自定义固件方案

触发：用户纠正——(1) 三轮里"Studio 替代 Sentino 后台" 方向反了：Sentino 是 Agora 合作伙伴 + Agora Studio 是 Sentino 的浅层竞品（Studio 只做配置维护，Sentino 是打磨成熟的 Agent 平台）；(2) Sentino 也提供了基于 Agora R1 硬件的自定义固件方案（IoT 设备路径），这是 Sentino IoT 平台与 Agora RTSA + RTC 的完整端到端组合。

修正与新增： - concepts/agora-convoai-join-api — "Studio 与 Sentino 的关系（待评估）"段重写为 "Sentino 与 Agora Studio 的竞合关系"（含商务关系标注 + 6 维对照表 + 销售姿态明确为"Sentino 是升级路径，不会推 Studio 替代自己"） - projects/yukai-agora-poc — 待办那条"评估 Studio 替代 hot-reload" 改写为 "客户若提及 Studio，销售姿态是升级路径而非替代候选"（PoC 的操作员后台/多语言 QA 是 Studio 做不了的活，是差异化能力本身，不是重复造轮子） - projects/sentino-iot — 概述段加 商务关系标注（Sentino 是 Agora 合作伙伴） + 新增 "硬件接入路径（基于 Agora R1 硬件参考方案）" 段：客户用 R1 硬件 → 烧录 Sentino 自定义固件 → 连 Sentino IoT 平台（MQTT 信令获取凭证）→ Agora RTC/RTSA 实时语音传输 - projects/sentino-agent — 经验教训新增 "Sentino 与 Agora 的商务/产品定位（合作 + 竞合并存）" 条目：基础设施层是合作伙伴关系（Agora 推荐 Sentino），Agent 平台层是竞品关系（Studio 浅 vs Sentino 深）

三个值得记录的判断： 1. 合作 + 竞合（co-opetition）是 Sentino-Agora 关系的准确刻画——基础设施层合作（RTSA/ConvoAI/RTC 都用 Agora），Agent 平台层竞争（Studio vs Sentino Agent）。这是企业销售对话中要清楚定位的一条 2. Sentino IoT 在硬件端有具体的 R1 方案——不是"理论上能接 Agora 设备"，是确实写了基于 R1 硬件的自定义固件实现。这条是销售对家庭 IoT / 玩具客户的硬件可行性背书 3. 国内 vs 海外的 Studio 可用性差异不影响 Sentino 销售姿态——三轮里这条洞察的方向需要修正：不是"海外 Sentino 后台是 Plus，国内是必需"，而是两种场景下 Sentino 都是更深的版本，区别只是在客户从哪起步（Studio → Sentino vs 直接 Sentino）

五轮补充：Sentino 固件仓库实证（含一处自我纠正）

触发：用户提供 Sentino 固件实际仓库 sentino-jp/sentino-iot-sample（GitHub private）+ 完整 README。三个新事实： 1. Sentino 把 Agora ConvoAI 服务封装代理给客户——README 原话："使用 Sentino IoT 平台接入时，Agora ConvoAI 服务由 Sentino 统一提供，开发者无需单独向声网申请开通"。这是合作伙伴关系最具体的商业落地表述 2. Sentino 固件 fork 自 Shengwang-Community/Conversational-AI-IOT-Sample（声网官方）——之前 wiki 写的 AgoraIO-Community/Conversational-AI-IOT-Sample 不算错：Agora 与声网是同一家公司（海外品牌 Agora、国内品牌声网），同一份代码在 GitHub 有两个 mirror（AgoraIO-Community 海外组织 / Shengwang-Community 国内组织），代码相同；Sentino README 致谢的是国内版 3. 完整链路实证：BLE 配网 Web App（Web Bluetooth API + BLE V1）→ BK7258（MQTT + RTSA Lite）→ Sentino IoT 云端 → Agora SD-RTN → AI Agent；用户操作流：编译烧录 → 启动 web-app 配网 → 短按 S2 启动语音对话

修正与新增： - projects/sentino-iot — "硬件接入路径"段大幅扩展：加完整链路图 + 仓库结构（device/ + web-app/）+ 用户操作流 + "Agora ConvoAI 由 Sentino 统一提供" 关键产品事实 + fork 自 Shengwang-Community 致谢 + private 标注 - concepts/agora-rtsa-sdk — Sentino BK7258 路径从"大概率走 RTSA Lite"升级为"确定"+ 标注 Sentino 实际仓库 sentino-jp/sentino-iot-sample（fork 自 Shengwang-Community）+ 同时列出 AgoraIO-Community 与 Shengwang-Community 两个 mirror（代码相同 = Agora/声网是同一家公司） - concepts/bk7258-firmware — RTC SDK 段同步纠正仓库名 + 加 Sentino 自家 fork

关键纠正记录（防再错）： - Sentino 固件仓库 = sentino-jp/sentino-iot-sample（GitHub private） - 声网官方原始仓库 = Shengwang-Community/Conversational-AI-IOT-Sample（国内 mirror）= AgoraIO-Community/Conversational-AI-IOT-Sample（海外 mirror）；Agora 与声网是同一家公司，代码相同 - Sentino 商业角色 = Agora ConvoAI 服务的代理/封装方——客户用 Sentino IoT 接入时不需要单独向声网申请 - 配网工具 = web-app/ 目录的浏览器 Web Bluetooth API + BLE V1 协议 - 启动语音对话 = 配网完成后短按开发板 S2 键

两个值得记录的判断： 1. Agora = 声网是同一家公司——海外品牌名 Agora、国内品牌名声网；GitHub 上 AgoraIO-Community 和 Shengwang-Community 是同一份代码的两个组织 mirror。Sentino fork 致谢中国版仅是文档习惯（可能因为 Sentino 团队主要接触声网中文资料），不构成"Sentino IoT 主要市场偏国内"的证据——市场定位需要看其他事实判断。这是 corrigendum：上一稿这条洞察的因果链是错的 2. "由 Sentino 统一提供 Agora ConvoAI"是对外销售的强表述——客户不需要自己申请声网账号 / 配置 ConvoAI / 维护 customer_key。这把"用 Agora"从客户的工程负担转化为 Sentino 的代理服务，是 sentino-iot "终端直调（Sentino 就是后端）"架构的具体落地

摄取 Agora RTSA C SDK 三篇官方文档

来源： - raw/snippets/agora-rtsa/implement-transmission.md（https://doc.shengwang.cn/doc/rtsa/c/get-started/implement-transmission） - raw/snippets/agora-rtsa/data-stream.md（https://doc.shengwang.cn/doc/rtsa/c/advanced-features/data-stream） - raw/snippets/agora-rtsa/encryption.md（https://doc.shengwang.cn/doc/rtsa/c/advanced-features/encryption）

新建页面

关键知识提取

  1. RTSA 全称澄清：Real-Time Streaming Acceleration — 用户原描述"Real-Time Streaming Audio"是常见误读，第一个 WebFetch 把它读成"Real-Time Server API"也是错的。声网官方现称"媒体流加速（原实时码流加速）"，是面向 IoT 嵌入式设备的轻量 C SDK 而不是面向服务端的 API。事实核查 WebSearch 给出权威解释——纳入 raw 与概念页"定义"段第一句 → 与 naming-shapes-thinking 同源：缩写 + 模糊全称导致信息传播过程中持续偏移；在概念页第一行强制锚定全称是反信息腐蚀的工程

  2. Sentino BK7258 固件用 RTSA 从猜测升级为行业标准 — 官方 Convo AI Device Kit R1 直接就是 BK7258 + RTSA Lite + ConvoAI 的组合；开源参考实现 AgoraIO-Community/Conversational-AI-IOT-Sample 直接演示该集成。这意味着 Sentino 不是在"自创"链路，是走 Agora 官方推荐路径。对外讲 Sentino 技术栈时这条事实可以作为"我们选 Agora 不是绑死"的反向论据——是行业事实标准而不是供应商锁定 → 与 bk7258-firmware 直接连接：原页面只说 CPU0 跑 RTC、CPU1 跑媒体处理但没具体讲 SDK 类型，本次摄取把"RTSA Lite"明确写入；与 sentino-iot 设备层技术栈也精确化为 RTSA 而非笼统的"Agora RTC SDK"

  3. OPUS/16kHz/20ms 是 RTSA SDK 发送约束本身，不是产品决定 — (640 × 1000) / (16000 × 1 × 2) = 20ms，发送间隔必须严格等于帧长。agora-rtc-voice 既有页面记录的"OPUS / 16kHz / 单声道 / 16bit PCM / 20ms"参数表，本质来自 RTSA SDK 的 send API 硬约束，不是 Sentino 或某客户的设计选择 → 在 agora-rtc-voice 中加入这条出处说明，把高层产品视角（设备做什么）与底层 SDK 视角（SDK 约束什么）的因果关系打通

  4. Data Stream "可靠 + 无序" 不存在是协议层逻辑约束的范例 — 4 种 reliable/ordered 组合中 SDK 拒绝 reliable=true & ordered=false。原因不是工程偷懒，是逻辑约束：重传必然带顺序约束，否则重传到达后位置无意义。这是工具/协议设计文档应该显式标注的"看似缺失实为不可能" → 与 agent-tool-design 工具设计哲学连接：好的工具协议应在文档中显式说明"为什么这个组合不存在"——不写出来，集成方会反复问"是不是 SDK 还没实现"

  5. RTSA 把"采集 + 编解码"踢出 SDK 是第一性原理删减在 SDK 设计上的范例 — RTC SDK 内置采集 + 编解码；RTSA SDK 选择不内置，让设备自己出编码后的帧。这是"必须这样做吗"在 SDK 边界划分上的应用——通用音视频通信 SDK 的"必须内置编解码"假设，在 IoT 嵌入式场景下被首先质疑：设备千差万别（不同 SoC、不同 codec ASIC、不同采样能力），强制 SDK 内置反而限制了适配空间 → 与 first-principles-deletion 三个质疑直接对应：第二问"必须这样做吗"删方案；同时与 harness-engineering 的 Environment 层工具划分同源——把"通用且不可省"封进 SDK，把"设备相关 + 编码格式百花齐放"留给应用，是 Tool/Environment 边界设计的工程样本

  6. E2E 加密 Agora 服务端不持密钥，与服务端 ASR 互斥假设未明说（TTS 不互斥） — 8 种加密模式 + 密钥与盐由开发者自家服务端生成 → Agora 看到的只是密文。这是隐私敏感客户对外承诺的硬技术保证。加密原理决定 Agora ConvoAI Agent 必须听到明文音频才能转写并驱动 LLM——理论上启用 E2E 加密互斥服务端 ASR。TTS 一侧不构成问题：Sentino 实际走"半自定义模式"（见同日更新的 agora-convoai-join-api llm.output_modalities=["text","audio"] 段落），Agora 本就不调度 TTS，音频由 Sentino LLM endpoint 内部出。RTSA 文档对此没明说，需要实测或问 Agora 工程 → 与 sentino-tenga 隐私答案直接关联：TENGA 性健康场景"端到端加密 + ConvoAI 链路是否可兼得"已精细化为只剩 ASR 一侧权衡，写入 sentino-tenga 项目页"工程实现的隐藏风险"段；与 agora-convoai-join-api rtc.encrypt 字段表标注补充推断的副作用 → 元教训：主流文档讲"我们支持加密"时往往不讲"启用后哪些既有功能会失效"——这是平台 SDK 文档的典型盲区，集成方容易在加密一启就发现 ASR 不通，需要架构层提前问 → 二阶教训：E2E 加密 + Sentino 半自定义模式 = TTS 一侧的"隐私 + 音频生成"全收回 Sentino 内部——这是半自定义模式的隐藏价值之一，原本只看作"TTS 厂商选型自由"，现在多一层"隐私敏感场景的 TTS 段不被 Agora 触碰"

  7. Data Stream 速率上限解释 ConvoAI 的 data_channel 配置语义 — 60 包/秒 + 1KB/包 + 聚合 30Kbps = 旁路控制通道而非数据通道。agora-convoai-join-api parameters.data_channel: rtm 信令 vs rtc datastream 选 datastream 时实际只够送 turn_detection 状态、字幕事件、控制位标记等稀疏信令——业务数据必须走音视频通道或 HTTP 回调 → 在 join API 字段表 datastream 行加入这条速率约束注解，让"按客户编排决定"的判断有具体上限可参考

更新页面

事实核查记录

声明 核查方法 结论
RTSA 全称是 Real-Time Streaming Audio（用户原描述） WebSearch 错误——官方为 Real-Time Streaming Acceleration（"实时码流加速"，现称"媒体流加速"）；首个 WebFetch 给的"Real-Time Server API"也是错的
RTSA 是面向 IoT 嵌入式设备的 C SDK WebSearch + 官方文档 属实——支持 Linux/Windows/iOS/Android/freeRTOS/嵌入式 RTOS，包体 < 400KB
Sentino BK7258 固件用 RTSA WebSearch 高置信度——官方 Convo AI Device Kit R1 直接就是 BK7258 + RTSA Lite + ConvoAI 的组合，开源参考实现 AgoraIO-Community/Conversational-AI-IOT-Sample 演示集成；BK7258 是 Beken 高度集成的音视频 Wi-Fi SoC，三核 Cortex-M33 + freeRTOS V10，适合 RTOS-based RTSA SDK 集成
RTSA 与 RTC SDK 协议互通 WebSearch + 官方文档 属实——底层走同一张 SD-RTN，IoT 设备（RTSA 端）可与手机/浏览器（RTC/WebRTC 端）直接互通
OPUS/16kHz/单声道/20ms/640 字节帧 = 20ms 间隔 官方 implement-transmission 文档第一手 属实，公式 (640 × 1000) / (16000 × 1 × 2) = 20ms
Data Stream "可靠 + 无序"组合 SDK 拒绝 官方 data-stream 文档原文 属实，文档明确给出 4×组合矩阵第二行 ✗
8 种加密模式（推荐 GCM2）+ Agora 服务端不持密钥 官方 encryption 文档第一手 8 种模式列表 + 推荐 GCM2 属实；密钥分发由开发者服务端生成属实；"Agora 服务端不持密钥"是基于"密钥从未上传 Agora"的逻辑推断，文档未直接声明
E2E 加密与 ConvoAI 服务端 ASR/TTS 互斥 官方 encryption 文档未明说 未核实——基于加密原理推断，文档未明确说明，已在概念页和项目页明确标注"推断"和"待实测"；TENGA 客户对接前必须实测验证
客户文档陷阱专项检查 本次素材是 Agora 官方技术文档而非客户向 PRD/RFP/合同 不适用——三篇都是 Agora 官方对开发者的 SDK 文档，不存在"第三方品牌名是能力代名词 vs 选型"的污染风险

待办与开放问题

摄取 Founder Park 对谈 CREAO：20 人团队、每天上线 8 个功能，在 Pivot 产品之前我们先 Pivot 了组织

来源：raw/notes/founder-park-creao-organizational-pivot-2026.md（Founder Park 公众号《对谈 CREAO》访谈：万户/编辑：夏天，2026-04 公开发布；非 Sentino 客户文档，纯行业分析；上篇 CREAO 摄取在 2026-04-14 的 Peter Pang X 长文，本次给已有 ai-first-engineering 加深而不是新建独立 CREAO 概念页）

新建页面

关键知识提取

  1. "产品不是护城河，组织效率和 pivot 速度才是" — CREAO 程凯核心金句。今天所有 AI 产品都是中间态，能活到最后的不是产品最好的而是反应最快的。Cursor / Lovable / Devin / Replit 都在执行同样的隐性共识。这条把 ai-agent-moats "feature moat 已死"判断升级为可操作护城河——单点功能在中间态会被 pivot 走，但跨形态的 pivot 能力保留 → 与 ai-agent-moats 同源对照（feature moat 已死）；与 platform-layer-collapse 反向窗口（创业公司组织灵活度是中间层之外的存活窗口）；新建 pivot-speed-as-moat

  2. CREAO 自身 Vibe Coding 平台失败是供给侧反例（公司自己用不起来自己产品） — 2025-09 上线 → 几个月内 marketing/产品/工程团队都搭不出能用的应用 → 自我证伪 → pivot 到 Super Agent。本次摄取最有杀伤力的反例——做 vibe coding 平台的公司自己用不起来 vibe coding。复盘：认知错误是"给人构建传统工具"，应该是"AI 给自己构建工具"——AI 不需要 UI 不需要交互界面 → 与 vibe-coding-creator-motives 6% 完成率消费侧观察形成同一现象的供给侧呈现；与 agent-ui-is-product "UI 是仅存差异化"判断在 AI 主导经济体细分赛道形成对立（AI 主导路线 UI 不是核心战场）

  3. 架构师 = 六边形战士（产品/商业/行业/技术通才）— Clark Gao 给"AI-first 时代架构师"具体定义。传统技术架构师只覆盖第 4 项；AI-first 架构师必须四项都到一定程度，因为他要在 AI 自动生成的需求任务里做"挑哪些推进"的判断 → 与 experience-over-knowledge "经验是包袱"反向陷阱同源——元能力（跨域判断/范式切换灵活度）> 单域经验 > 知识。本次给该页论点加一层修正

  4. 环境稳定 > 智商高的 50→90 分论断 — CREAO 把 harness-engineering "Agent = Model × Harness" 乘法关系给出当前阶段的具体分量：Harness 占 50→90 那 40 分，模型才占最后 10 分。"今天有多少人完全利用到了大模型所有的智商？很少。" → 与 harness-engineering 直接连接：本次给该页加入"两层 Harness 定义（用户层 vs 平台层）+ iOS vs Android 类比 + 50→90 分论断"完整段落；对 Sentino 含义：LLM 选型决策的优先级应该重新校准——Harness 层是 40 分级杠杆，模型层是 10 分级

  5. Coding Agent 是 connector 的元工具（Amplitude 案例 + Marketing 抓取案例）— Peter 概念厘清：Coding Agent 不只是"写代码"，更重要的是文件系统访问/memory 管理/工具调用/API 调用/长时间稳定运行。写代码能力让 agent 通用，是因为大部分任务遇到边界情况需要 agent 自己现写代码——这是 mcp-protocol 的反向（MCP 是先定协议，Coding Agent 是现场写） → 与 agent-tool-design 直接连接：本次给该页加"反向：Coding Agent 是 connector 的元工具"段落；对 sentino-agent Standalone Agent 工具集设计的启示——可以引入 Coding Agent 能力扩展长尾覆盖

  6. 不做 Marketplace 的判断（agent 工作流个性化导致不可移植） — CREAO 改做 workspace 内协作。"每家公司最后一公里无法标准化（金融公司同样做交易 90% 工作流一样剩 10% 独有）"。"现在需要 Marketplace 是因为大家不知道怎么开始；未来 AI 自己就会知道这些" → 与 sentino-agent Standalone Agent SaaS 分层（个人/团队/Enterprise）的直接借鉴——分层重点应该放在协作（共享 agent / context 给同事）而不是交易市场，否则会撞上工作流个性化导致 agent 不可移植的根本问题

  7. Skill vs Agent 的层次区分 — Skill = Agent 的 Runbook（基础设施层正常运行的文档），Agent = Skill + Memory + Widget + Schedule。Skill 不是终极抽象，Agent 比 Skill 多三层。在七层模型中 Skill 在 Layer 7，Agent 还需要 Layer 3（Memory 预取）+ Layer 6（Task 调度）+ UI 层 → 与 agent-tool-design / agent-runtime-architecture 直接连接：对 Sentino Standalone Agent 设计的启示——当前覆盖了 Skill + Schedule，Memory 是隐性的（由主 Agent 通过 read_xx 工具被动查），Widget 在语音输出。如果未来要扩展 App 内查询/Web Dashboard/Webhook 推送，Widget 层会变得关键

  8. 三层 Memory 管理机制（Thread 内压缩 / 跨 Thread 提取 / 新 Thread top-15 注入） — 跨 Thread 提取走独立服务（不阻塞主流程）= harness-engineering "Side Query" 原则的具体应用；新 Thread 加载 top-15 是与 sentino-memex "<500 active gists 时全量返回"思路的另一极——CREAO 用 top-N 排序裁剪，Memex 用 4 级 TTL + 阈值控制总量。两条路径都是回避向量检索 → 与 agent-runtime-architecture Layer 3 prefetchMemoryAndSkills 直接连接：补强为"Layer 3 不是单一动作，是三段流水线"（压缩 / 提取 / 注入）

  9. Sandbox 启动时间从 10-20s 优化到 <5s（CREAO 也是评估 Claude Code 后选择自建） — 行业第二独立样本支持 sentino-agent 自建 Agent Loop 决策。关键含义：Sentino 自建决策本来是单一团队判断，现在多了 CREAO 同向证据，可在对外材料/团队对齐时引用作为决策合理性的行业背书 → 与 claude-agent-sdk / agent-runtime-architecture Layer 5 直接连接：执行隔离不只是安全约束（Permission 视角），也是性能约束（避免 agent 间环境干扰导致的"无限调优循环"）

  10. AI 主导 vs 人主导经济体二分对 Sentino 战略的判定价值 — Sentino 同时押两个对角象限（IP 玩偶=个体 AI+人主导 vs Agent 平台=组织 AI+AI 主导）。这不是分裂是产品线分层，但两条路线护城河逻辑、设计目标、增长曲线都不同——人主导路线护城河在 IP/情感/品牌；AI 主导路线护城河在协议设计/工具集/Agent 工程能力。需要内部资源分配明确：哪些团队/路线服务人主导，哪些服务 AI 主导 → 与 individual-vs-institutional-ai 正交构成 4 象限；与 sentino / sentino-agent 战略选择直接挂钩

  11. "95% 工作交给 AI" 是 AI-first 的操作定义 + 自检命题 — 程凯给 AI-first 一个具体可量化的判断：不是嘴上说，不是加几个 AI 工具，是 95% 工作交给 AI。自检命题："如果你自己的公司都做不到 AI first，你凭什么做出一个帮别人 AI first 的产品？" → 与 sentino / sentino-agent 销售可信度直接相关——Sentino 给 TENGA / YUKAI / Hotmind 卖"AI 改造业务"，自身 AI-first 程度是销售可信度的根基。本次在 sentino-agent 加入 AI-first 自检待办段落

更新页面

事实核查记录

声明 核查方法 结论
程凯（Cheng Kai）= CEO WebSearch 属实，Crunchbase / aibase / 多源
Peter Pang = CTO（原文表述） WebSearch LinkedIn 显示其 title 是 Co-Founder@Creao AI, ex-GenAI@Meta（scale LLaMA 经验）。Founder Park 文章按 CTO 称呼——可能是公司内部职责分工，记录差异，按原文表述保留
Clark Gao = 增长负责人（原文表述） WebSearch LinkedIn 显示其 title 是 Co-founder & CPO @ CREAO AI。原文按"增长负责人"——可能 CPO 兼增长 GTM 职责，记录差异
公司 2025-01 底成立 WebSearch aibase 等中文报道写"end of 2024 / 2024 末成立 / 2025 初公司开始运作"——基本一致
融资累计超 3000 万美元 WebSearch 公开资料 2025-07-31 公布 Seed + Pre-A 由云启 / Monolith 领投，多家参投，金额表述为"multi-million"——独立数据未到 3000 万美元；本文所述可能包含未公开的后续轮次或更高估值。本数据未独立核实，按原文转引保留并标注
Super Agent 2026-03-31 上线 WebSearch 属实，testingcatalog.com / creao.ai/blog 多源；agent.creao.ai 域名公开访问
ARR 4x / ARPU 普通 C 端 6-7 倍 WebSearch 未查到独立公开数据，按原文转引保留
14 天每天 5-8 个功能上线 引用对照 与 ai-first-engineering 已记录的"3-8 次/天"基本一致
Claude Code 启动时间 10-20s 早期 行业经验印证 Claude Agent SDK 部署文档承认每实例 ~1 GiB RAM + Node.js 子进程启动开销，10-20s 与该实例规格匹配
客户文档陷阱专项检查 本次素材是 Founder Park 公开访谈而非客户向 PRD/RFP/合同 不适用——纯行业分析，不存在"第三方品牌名是能力代名词 vs 选型"的污染风险

待办