概述¶

sentino Agent 平台当前专注的是实时语音交互——围绕"用户与 AI 在毫秒级延迟内连续语音对话"这一场景设计架构与能力栈。负责 LLM 推理调度、TTS 语音合成、Function Calling 和记忆管理。它不负责音频传输，但负责语音生成（TTS）和文本推理（LLM），通过 HTTP 回调与 Agora Agent 协作。

与 sentino-iot 共享同一套工作流引擎，但有独立的 Web 路径（浏览器 + Agora RTC Web SDK）。

当前 scope 边界（2026-04-29 明确）¶

"实时语音交互"是 Agent 平台面向终端用户的主产品形态——围绕"用户与 AI 在毫秒级延迟内连续语音对话"设计架构与能力栈。但 scope 不止于"前台实时对话"——围绕这个主形态的纯独立 Operator 任务也在 scope 内：

在 scope 内（已通过 Agent Art 架构支持）：

• 前台实时语音交互——主 Agent 在对话中调度 LLM / TTS / 工具 / 记忆，毫秒级响应

• 三种触发-回执时序的 Operator 任务（Sentino 架构都能承载）：

不在当前 scope 内：

• 多小时级复杂自治代理（如 Manus / Devin 类"接到模糊任务后自己规划几小时完成多步骤工程改动"）— 与现有 Agent Art 的"单一目标 + LLM 自判完成"不同量级，需要任务规划 / 长期 state / 自我纠错 / 跨会话委托模型等当前未投入的工程
• 纯文本 / 屏幕交互产品（如 web chatbot / Slack bot 类作为独立产品）— 底层能力可以支持，但 TTS / VAD / 实时性优化等核心工程投入都假设语音通道存在，纯文本场景边际差异化不大

对 三元论 Agent Art 形态的修正：之前"Agent Art 主要是 Refiner，Operator 能力较弱"判断收得太窄——只想着外部 SaaS state alteration（Stripe API / 发邮件 / Computer Use），且把"异步"和"独立"混为一谈。实际三种触发-回执时序的 Operator 都能在现有架构里跑，Operator 演进真正的工程缺口在"改变什么"（外部 SaaS state alteration 涉及 Liability Wall 硬约束）而不在"什么时候触发 / 什么时候回执"。详见 agent-creator-refiner-operator "对 Sentino Agent Art 的诊断"段（已同步修正）。

架构¶

四层结构：

• 前端（workflow-web）：React + Vite，集成 Agora RTC SDK（音频）和 RTM SDK（实时转写），通过 HTTP 管理 Agent 生命周期
• 后端（workflow-api）：AgoraAgentController（Agent 启停）、AudioController / MeetingController（接收 Agora 回调）、AgentWorkflowExecutor（工作流编排）、PostgreSQL + Redis
• 核心引擎（workflow-engine）：LLMProviderFactory（Gemini/OpenRouter/Grok/VertexClaude/MiniMax）、TTS Provider（Minimax/ElevenLabs/Qwen3）、FunctionCallProcessor。长期记忆走外部独立服务 sentino-memex（HTTP 调用，详见"关键决策"段）
• Agora 云服务：SD-RTN（实时音频网络）、Conversational AI Engine、ASR（Agora/Soniox）

核心数据流：

1. 前端 → 后端 → Agora ConvoAI API 创建 Agent
2. 用户麦克风 → RTC SDK → SD-RTN ↔ Agora Agent（双向音频）
3. Agora Agent ASR 转文本 → HTTP Callback → 后端 /api/audio/chat
4. 后端执行工作流：LLM 推理 → Function Calling → 记忆检索
5. LLM 流式文本 → Agora Agent → TTS 合成 → RTC 音频回传用户
6. RTM 通道推送实时转写字幕到前端

关键决策¶

• 平台不碰音频传输：Agora 负责音频传输和 ASR，Sentino Agent 负责 LLM 推理和 TTS 语音合成，生成的语音回传给 Agora Agent 再经 RTC 送达用户
• 多模型适配：LLM 支持 Gemini、OpenRouter、Grok、VertexClaude、MiniMax；TTS 支持 Minimax、ElevenLabs、Qwen3
• 双回调入口：AudioController（标准语音对话）和 MeetingController（会议模式），共享同一套 WorkflowExecutor
• 长期记忆：自研 Memex 服务提供跨会话记忆能力（Spring Boot + PostgreSQL，三段流水线 Blob→Summary→Profile/Event/Gist，4 级 TTL 衰减 + Reinforce 抗膨胀）
• Agent SaaS 是 agent 核心概念的 source of truth（2026-04-29 决策落地）—— Agent / Agent Art / Skill / Tool / Memex / Workflow 等所有"智"层概念由 studio.sentino.jp（用户面向的 SaaS UI / Console）+ api.sentino.jp（后端 API endpoint） 共同承载：用户在 studio UI 上创建 / 配置 / 管理，后端 CRUD 走 api，外部集成方（如 Agora ConvoAI、客户服务端）也直接调 api；sentino-iot 平台仅做配置展示（拉 Agent SaaS 数据展示给终端用户/设备绑定，不做 CRUD）。详见 sentino "决策状态" #1

Arts 抽象（Sentino 平台核心概念）¶

Sentino Agent 平台把"主 Agent 可调度的能力单元"统一抽象为 Art——三种具体形态聚合在同一个抽象层之下：

重要澄清：Agent 这种 Art 形态的早期讨论里常用 "Standalone Agent" 称呼，前缀容易误导。Agent Art 实际有三种触发模式，"独立于对话运行"只是其中之一：

Tool / Skill 也都可被主 Agent 按需调用——三种 Art 形态的区分是内部执行特征（单步 / 组合 / 自判循环），不是调用模式。三种形态都能被主 Agent 调用，只有 Agent 形态额外支持时间/事件触发。

Arts 抽象的工程价值¶

1. 统一调用接口——主 Agent 不区分"调 tool / 调 skill / 触发 Agent Art"，统一通过 Art 引用调用
2. 统一配置入口——用户/客户创建 Art 是同一个流程（指令 + 触发 + 输出形态），底层路由到三种形态之一
3. 统一治理层——权限 / 计费 / 审计 / 调用日志在 Art 层做，三种形态共用
4. 与 Operator 三时序解耦——三种 Art 形态都能承载同步 / 异步 / 独立三种 Operator 触发-回执时序，invocation 模式由 Art 配置决定，不绑死在形态上（参考"scope 边界"段对三种时序的展开）

与外部 agent 平台抽象的对照¶

Sentino 把三形态聚合在一层是设计上的赌注——降低主 Agent 调度复杂度 + 降低用户配置心智，但 Art 抽象内部三种形态在生命周期 / 错误处理 / 输出格式上仍有差异，未来如果某一形态独立演进过快可能撑不住聚合（如 Agent Art 演进出 Manus / Devin 类多小时复杂自治形态时）。

Agent Art 架构（早期称 "Standalone Agent"，2026-04 设计）¶

Agent 是 Art 三种形态之一（与 Tool / Skill 并列）。本节聚焦 Agent 形态的具体架构设计；Tool / Skill 形态的统一调度由 Art 抽象层承载。

历史命名说明：本节早期文档里 "Standalone Agent" 是 Agent Art 的同义词，前缀"Standalone"会误导成"只能独立运行"——实际 Agent Art 有三种触发模式（时间触发 / 事件触发 / 主 Agent 按需调用），独立运行只是其中一种。下文统一使用 "Agent Art" 表述。

战略意义¶

由于 sentino-iot 的 API 是面向终端直调的（App→Sentino 云，客户没有自己的后端），Agent Art 实际上是整个架构中唯一的可编程扩展点——它替代了客户本来会写在自己服务端的自定义逻辑。这不是一个"附加功能"，而是产品可扩展性的核心承载。

管理入口问题：Agent Art 目前只在 Agent SaaS（studio.sentino.jp UI / Console）管理，后端 CRUD 走 api.sentino.jp。但无技术客户（画像 A）只认识 IoT 侧的 App（api-iot.sentino.jp）。需要决定 Agent Art 管理入口是：(a) IoT App 嵌入 studio.sentino.jp WebView (b) IoT 后端反向代理 api.sentino.jp (c) 接受能力分层（无技术客户用不了 Agent Art 高级配置，只能用预设 agent）。详见 sentino "双网关架构 → 决策状态 #4"。

问题¶

平台需要让用户自建 Agent Art 与主 Agent 配合。三种方案评估后选择了 Agent Loop 模式：

核心洞察：用户只需表达意图（prompt + 工具选择），不需要设计流程。Agent 循环自行判断是否完成目标。

工具化集成模式¶

Agent Art 是数据生产者，主 Agent 是通信层：

Agent Arts（后台运行）
    ├── 定时/事件触发 → Agent Loop → 结构化 JSON 输出
    ├── 存储到 agent_outputs/{agent_id}/latest
    └── 如果紧急 → 写入 notification_queue（带优先级）

主 Agent（语音对话）
    ├── 工具: read_xx(agent_id)              ← 拉模式
    ├── 每轮对话前检查 notification_queue     ← 推模式
    └── 所有输出 → 统一人格 → 语音

为什么选择工具化而非直接输出给用户：语音产品有硬约束——单通道、线性输出。工具化方案保证： - 人格一致性：所有输出经同一个声音和人格 - 信息综合：主 Agent 可合并多个 agent 数据一次说清 - 追问能力：用户可在语音对话中自然追问 - 语音体验：像和一个人聊天，而非收系统通知

Agent Art 的三个消费者¶

Agent Art 是独立的数据服务，主 Agent 只是它的消费者之一：

Agent Art 数据输出
    │
    ├── 1. 主 Agent（read_xx 工具）    ← 语音对话
    ├── 2. 用户直查 API                ← App / Web UI
    └── 3. 第三方系统 Webhook           ← Enterprise 集成

每个 Agent Art 创建后自动获得： - 主 Agent 工具集成：自动生成 read_xx 工具，主 Agent 可在语音对话中调用 - 数据查询 API：GET /api/agents/{agent_id}/data，用户/第三方可直接查询 - 信号接口：紧急事件写入 notification_queue，触发主 Agent 主动发言（推模式）

自建 Agent Loop vs Claude Agent SDK¶

评估 claude-agent-sdk 后决定自建，原因： - Agent Art 需要的工具是平台侧能力（查设备/调 API/读用户数据），非 SDK 内置的文件/Shell 操作 - 避免单一供应商锁定 - 资源开销更轻（无需 Node.js 子进程） - 与主 Agent 原生集成

借鉴 SDK 的设计思路：Agent 自判目标完成的循环模式。但成本控制（max_turns、预算上限）等属于 Enterprise 层特性，普通用户界面不暴露。

SaaS 分层设计¶

普通用户和 Enterprise 用户看到的是同一个创建流程，不同的控制深度：

普通用户——极简创建： - Agent 名称 + 指令（自然语言）+ 工具选择（勾选）+ 触发条件 - 平台在后台用合理默认值兜底（调用次数、成本），用户界面不出现这些概念 - 创建即可用：主 Agent 语音集成 + 数据查询 API

Enterprise——治理层叠加：

核心原则：普通用户的界面里不出现 Enterprise 概念。 预算、审计、权限这些词不应该出现在普通用户的视野里。

CREAO 同规模 AI 创业的对照启示¶

CREAO（20-25 人，AI Agent 平台公司）是 Sentino 同量级、同 Agent 平台赛道、同样押注 AI 主导经济体的直接对标样本（详见 ai-first-engineering 完整 + pivot-speed-as-moat / ai-economy-vs-human-economy）。

Sentino "六边形战士" 角色评估¶

Sentino 当前已知团队角色（参考 user 自建 memory）： - Lawrence（CEO）= 日常运营 + 对外接客户 + 定方向 - Chris（董事长）= 战略 + 资本 + 大方向 - 子昕（产品）= 产品品味 - 姜涛（技术负责人）= 技术 - 其他岗位（按当前组织规模约 10-15 人）

按 CREAO "六边形战士" 标尺：CEO + 董事长共同承担六边形战士角色（产品品味 / 商业认知 / 行业理解 / 技术掌握），但实际能否在四个维度都达到入门级以上需要客观评估。如果四个维度有明显短板，需要补人或拆分架构师角色。Sentino 的 CEO + 董事长双角色结构理论上可以让两人各承担不同维度（例如 Chris 偏战略/资本，Lawrence 偏运营/客户）——前提是两人对四个维度的覆盖加起来无短板。

这是 experience-over-knowledge "经验是包袱"反向陷阱在 Sentino 的具体应用题 ——团队中谁的经验是 AI-first 范式的资产、谁的经验是包袱？

Sentino "AI-first 自检"待办¶

• 工程职能：当前 AI 写代码占比？是 ai-first-engineering 95% 操作定义还差多远？
• 产品职能：PRD / 需求 / spec 是否 AI 主动发现 + 提出？
• 客户支持：YUKAI / Hotmind / TENGA 项目沟通中 AI 处理比例？
• 销售：sentino-memex-positioning 销售材料是否 AI 协助生成？
• 自检命题（ai-first-engineering）：如果 Sentino 自己的公司都做不到 AI first，凭什么做出帮别人 AI first 的产品？

Amphiflow 视角的 Agent Art v2 评估¶

张铁蕾 2026-04 提出的 amphiflow 模式（默认 workflow + agent 自动兜底，依赖 decision-execution-decoupling 实现）给 Agent Art 演进路径补充了一个第三象限选择——区别于"全 agent loop"和"全 workflow（Dify 式）"两条路。

当前 Agent Art 形态评估¶

当前 Agent Art = 纯 agent loop（指令 + 工具选择 + 触发条件 + LLM 自判完成）。amphiflow 视角下的潜在 v2 演进：

张力与判断¶

引入 amphiflow 有两条已知张力：

1. 与 agent-tool-design "逃生工具"原则：逃生工具假设运行时始终保留"现造工具"自由度，workflow 凝固后这种自由度受限——客户场景变化时 workflow 失效率上升
2. 与 CREAO "Coding Agent 是 connector 元工具"主张（ai-first-engineering）方向相反——CREAO 让 agent 现写代码扩展长尾，amphiflow 让 workflow 凝固通用路径。这是两条不同的 agent 演进哲学，混用会产生设计逻辑冲突

当前阶段判断¶

Sentino 当前阶段（早期 Agent Art + 客户量未起量）不引入 amphiflow——架构复杂度增加换来的 token 节省在当前规模下不划算。

触发重新评估的两个条件（任一满足应重新评估）： - Agent Art 实例数 >10K + 高频固定模式占比 >50%（此时纯 agent loop 的 token 成本结构开始难看） - 客户开始抱怨 Agent Art 行为不可预测（此时 workflow 凝固带来的稳定性增益压过自由度损失）

对外定位锚点¶

向客户/合作方/投资人讲 sentino-memex 的核心销售锚点：Sentino 走文本结构化记忆路线，与 Anthropic Claude Code 同方向，与 mem0 等向量检索方案是不同代际的判断。

完整产品论证（向量检索的固有问题、Anthropic 背书、行业共识 2025–2026 转变）见 sentino-memex 「对外定位锚点」段。

适用边界：通用 Agent 记忆基础设施场景 mem0 仍合理；Sentino 专注"记忆质量直接决定用户留存"的关系型 AI 产品（陪伴/语音/咨询）。

完整客户向说明文档：/Users/momo/local/claude-code/sentino-memex-positioning.md（同步推到 iot-docs/sentino/memex-positioning.md 中英文版）。

Google Agent Platform 4-pillar 词汇借鉴 + Govern 三件套预警（2026-04-28）¶

2026-04-28 摄取 google-agent-platform 父概念页后明确：Google 把 agent platform 定义为 4 pillars × 18 components（Build / Scale / Govern / Optimize）——这是 Sentino 对外讲"我们也是 agent 平台"的必须对照参照系。可借鉴 4-pillar 词汇结构描述 Sentino 现状：

Govern 三件套预警（Agent Identity + Registry + Gateway）：

1. Google AP 与 Microsoft Agent 365 Entra ID 同方向——行业正在标准化 agent 治理框架（SPIFFE / X.509 / mTLS / DPoP）
2. Sentino 短期内追不上 Google AP 全栈，但企业客户问起来要有答案——至少销售材料里要有"治理路线图"段落
3. 重点关注：客户合规对接 SPIFFE / mTLS 是否成强制要求；Agent 行为审计要求是否会下放到 Sentino 这种中间层供应商
4. Memory revisions API + IAM（已写入 2026-04-28-memex-v2-design-options P1）是 Sentino Govern 柱的最小可行起步——不是要做完整 Agent Identity，是用 Memex revision 历史 + scope-based IAM 给客户合规要求一个最小可行答案

ADK graph-based 子 agent 网络的方向分歧（2026 行业三种路径）：

Sentino 当前是单 agent + 工具化集成 + Agent Art 数据生产者模式，没有显式 graph-based 子 agent 编排。三条路径并存于 2026 行业，Sentino 选哪条要在客户场景需求明确后再定——但当前不必跟随 Google ADK graph 化。

2026-04 销售对照样本扩展：从 mem0 单对照到 mem0 + Memory Bank 双对照¶

2026-04-28 摄取 google-memory-bank 调研后明确：销售姿态从"对照 mem0 一家"扩到"对照 mem0 + Memory Bank 两家"。两个对照样本差异化论证不同：

• vs mem0（向量检索路线，反方向）：用路线代际差异——向量检索的 4 个固有问题；Anthropic auto-memory 同方向背书
• vs google-memory-bank（同路线托管版，同方向）：不能用路线代际，必须用具体差异点——自主可控（不绑 Gemini）/ Reinforce 主动续期 / 4 级 TTL × 4 类内容二维结构 / 数据主权（自建 vs GCP 托管）/ 可深度定制

Memory Bank 是更难回答的对照样本——客户问"为什么不用 mem0"可以拿"路线代际"答；问"为什么不用 Memory Bank"必须用"具体能力对比 + 业务约束"回答。sentino-memex-positioning 销售材料应当补 Memory Bank 列，把差异化论点从单维（路线）扩到多维（路线 + 控制权 + 模型策略 + 数据主权 + 定制深度）。详见 sentino-memex "对外定位锚点 → 2026-04 销售对照样本扩展" 段。

Kim Graves 视角的销售姿态自检（2026-04-29 摄取）¶

2026-04-29 摄取 plg-sales-coordination（Kim Graves / Notion 美洲区总经理 / 前 Slack 销售从 $6M → $1.5B+ 时期 / 20SALES 创始合伙人）后，对 Sentino Agent 平台销售姿态有 5 个直接对照启示：

4 Why 框架在 Sentino 销售复盘中的应用（详见 why-change-why-you-why-now）：

• 在客户深度对话之前，先用 4 Why 自检——任一 Why 不清楚，先停止方案发散，回去摸底
• 给 Chris / Lawrence / Donnie 与客户高管对话准备 talking points 时，按 4 Why 结构准备而非按"产品功能介绍"准备
• 三客户线现状诊断：YUKAI 4 Why 已被项目立项回答 / Hotmind Why now 是关键销售澄清点 / TENGA Why change + Why now 都未答（与 sentino-tenga 2026-04-20 战略复盘"停止方案发散"判断一致）

cold calling 试点判断（详见 cold-calling-revival）：Sentino 当前没有 cold call 渠道，可能是被低估的差异化窗口——尤其对头部 IP 公司 / 玩具厂商 / 北美客户。试点应当遵循"新 cold calling"模式（研究锚定 + 多通道节奏），日本市场需要"邮件预约 + 电话深谈"序列适配商务文化。

跨境政策风险评估（2026-04-29 摄取 Manus 案后新增）¶

Manus 案（2026-04-27 NDRC 叫停 Meta ~$2B 收购）后，Sentino Agent 平台需要把"跨境政策风险"作为商务决策的新维度。Sentino 公司层面的边界讨论详见 sentino "Manus 案对 Sentino 出海架构的边界含义"段；本节聚焦 Agent 平台横向客户/合作方对接时的具体场景。

当前客户线的跨境政策风险评估¶

当前结论：现有客户线主要是日本本地业务，无显著跨境政策风险。

未来客户/合作场景需前置评估的维度¶

如果未来出现以下场景之一，需要在商务谈判前置评估跨境政策风险：

1. 客户主体在中国 + Sentino 提供 agent 服务 — 理论上不触发 FISR Measures（Sentino 不是中国实体），但客户的算法备案 / 数据出境合规需 Sentino 配合
2. 客户在欧美 + 数据来源含中国 — 触发中国《数据出境安全评估办法》+ 客户所在国的数据保护法（GDPR / CCPA 等）
3. 合作方是中国 IP / AI 公司 — 涉及合作 IP / 模型授权时，需评估合作方是否在中国监管 watch list
4. Sentino Agent 平台被收购的极端场景 — 收购方所在国触发对内审查（CFIUS / 日本《外汇法》），如业务 / 数据涉中国还可能触发中国数据出境审查

Operator 类演进的跨境监管不可逆维度¶

Agent 三元论中Operator 类应用的"不可逆错误"原本主要指技术不可逆（用户损失 / 名誉损坏 / 物理伤害）。Manus 案叠加了跨境监管不可逆新维度（详见三元论页 "Manus 案叠加" 段）：

• Sentino Agent Art 当前主要是 Refiner 形态，Operator 能力较弱
• 当 Agent Art 演进到 Operator 强化（"AI 替我办事"演进）时，需前置考虑客户 / 合作方 / 数据涉及的国别
• 不能只评估 Liability Wall（产品级法律责任），还要评估跨境合规 + 主体注册地选择 + 创始人国别身份

给销售姿态的具体含义¶

• 与客户讨论 Agent Art 创建时，了解客户实际业务部署区域 + 用户来源国别——这是给客户的合规基础信息，不是 Sentino 多事
• 涉及中国用户 / 中国 IP 的客户线，主动告知客户多层并行管制的现实（详见 chinese-investment-security-review 与中国其他跨境数据/技术管制的关系段）
• 销售材料中加入"跨境数据治理"段落，标明 Sentino 的能力 + 客户需要自行承担的合规责任边界

2026-05-04 PE-anchored FDE JV 的边界含义¶

Anthropic / OpenAI 2026-05-04 同日宣布 PE-anchored FDE JV（Anthropic JV $1.5B + OpenAI DeployCo $10B + Palantir FDE 模式行业级复刻）对 Sentino Agent 平台有 4 条边界含义：

1. 不直接威胁 —— Sentino 不在 mid-market AI distribution 赛道¶

Sentino 卖 IP-to-AI 玩偶 + Agent 平台，不卖 enterprise AI 部署服务。PE-anchored JV 的目标客户群（mid-market PE-owned portco）与 Sentino 客户群（IP 公司 / 玩具厂商 / 健康品牌 / 家庭场景）几乎不重叠。

2. Sentino 的 Partner Channel 路径是同源逻辑的不同规模实例¶

Sentino 决策 #4 落地的"中期：服务商 / 实施伙伴生态"路径与 PE-anchored AI distribution 是同一逻辑的不同规模实例——通过伙伴生态压缩客户 procurement 周期。

规模差量级，逻辑一致：通过伙伴生态把客户 procurement 周期从月级压到周级。

3. Operator 类演进的法律责任结构可参考 JV 模式¶

Agent 三元论 中 Operator 类应用的 Liability Wall（法律责任墙） 是结构性约束。PE-anchored JV 给 Liability Wall 一个资本结构实现路径——独立法律主体承担执行责任，主体公司保持"我们只是软件公司"姿态。

含义：当 Sentino Agent Art 演进 Operator 能力（"AI 替我办事"演进，sentino-agent scope 边界段已识别）时，可以参考 JV 模式的"独立法律主体 + 责任合同"设计——比 Action Board 用户级方案更适合企业客户大客单价场景：

详见 agent-creator-refiner-operator "Liability Wall 的 JV 模式实现" 段。

4. Sequoia "战略基础设施"姿态的间接信号¶

Sequoia 在 Anthropic JV（一般不与 PE 共同投资 + 出现在 Anthropic JV 阵营）反映 VC 把 mid-market AI distribution 视为战略基础设施。这条对 Sentino 的间接含义：

• 未来 Sentino 的 VC 是否会推动类似的"战略基础设施"型合作 —— 比如 Sentino 与 IP 行业 trade body / 玩具行业协会 / 健康品牌联盟合作做"IP-to-AI distribution"
• 如果发生，Sentino 销售模式会从"逐家 BD"演变成"渠道战略"层面，与 PE-anchored 模式同源
• 当前 watching point：进入 Sentino 销售战略议程，但不需要 actionable 动作 —— 等 1-2 年观察 PE-anchored JV 实际效果 + Sentino 自身规模到 $X 营收阈值后再评估

客户项目（在交付中）¶

• yukai-agora-poc — YUKAI Engineering 陪伴机器人 AI Agent PoC（2026-06 底交付）。首次以"Agora"对外名义服务日本玩具客户；也是 sentino-memex 首次对外白标客户战——PRD AC-08 写 mem0 只是行业能力代名词，Sentino 实际用 Memex 交付，配套销售材料 sentino-memex-positioning.md 中英文版已就绪；引入新增量需求：操作员管理后台 hot-reload prompt + 三模式状态机（Normal/Sleep/Lazy）+ TTS 唱歌——三项中 Lazy 模式和 TTS 唱歌可行性尚未验证
• hotmind-client — 家庭场景 IoT 助手客户机会（早期评估）。客户已自建硬件 + MCP server + REST + 通知通道 + ConvoAI 编排，Sentino 接进去只剩 LLM 推理 + Agent 工程。客户 RFP 是按"被招标 LLM 推理服务方"形态写，Sentino 实际用完整 Agent 方案适配——是 Agent 平台首次以 OpenAI 兼容 streaming endpoint 形态对外。Sentino 当前不使用 MCP，走传统 HTTP-as-tool 方案——把客户 REST API 包装成 LLM function calling 工具集（客户 MCP server 不消费）。与 YUKAI PoC 对照：YUKAI 全栈 Sentino 自由度高，Hotmind 接口被客户预先定死自由度低，差异化要落到 Agent 工程深度而非 LLM 推理

经验教训¶

• 语音产品的 Agent Art 必须经过主 Agent 中转，不能直接输出给用户——单通道线性输出是硬约束
• Agent Loop 模式在用户配置复杂度和 Agent 能力之间找到了最佳平衡点
• Agent Art 不只是主 Agent 的后台助手，它是独立的数据服务——API 查询是与语音集成同等重要的消费方式
• 成本控制、审计、权限矩阵等属于 Enterprise 特性，不应污染普通用户的创建体验
• 客户 PRD 里第三方技术名（如 mem0）通常是能力代名词，不是已选型——把它当成"客户预先选定"会浪费销售机会，正确做法是主动承担术语切换教育，让客户接受用我方方案实现（yukai-agora-poc AC-08 case：PRD 写 mem0，Sentino 用 Memex 交付）
• 客户 RFP 假设承包方形态（如"OpenAI 兼容 LLM 推理服务方"）vs Sentino 实际是 Agent 方案——文档与现实不对称是销售机会——避免被困在客户原本的报价模型里（按 token / 调用计费），主动重新定义双方边界为"完整 Agent 工程"，争取 PoC + 包月 / 人月模式（hotmind-client case：客户 RFP 写给"被招标 LLM 推理服务方"，Sentino 用 Agent 平台适配）
• Sentino 与 Agora 的商务/产品定位（合作 + 竞合并存）：Sentino 是 Agora 合作伙伴——基础设施层（RTSA / ConvoAI / RTC）由 Agora 提供并把 Sentino 作为推荐解决方案商。但在 Agent 平台能力上，Agora Studio 与 Sentino Agent 平台是竞品关系：Studio 只做"配置维护 + pipeline_id 引用"的浅层能力；Sentino 是打磨成熟的 Agent 平台（workflow / tool / Memex / 多客户隔离 / 角色权限 / prompt 版本管理 / 多语言一致性管控）。客户从 Studio 起步发现不够时升级到 Sentino 是正常路径，Sentino 不会推 Studio 替代自己。详见 agora-convoai-join-api "Sentino 与 Agora Studio 的竞合关系" 段
• Sentino LLM endpoint 接入 Agora ConvoAI 的标准配置（半自定义模式）：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）。详见 agora-convoai-join-api，调用代码参考 sentino-convo-ai 仓库。yukai-agora-poc 与 hotmind-client 共用此配置。Agora 既然提供了 tts.* 和 mcp_servers 字段，客户/竞品理论上可以让 Agora 自己调度 TTS + 工具，把 Sentino 退化为纯文本推理供应商——客户最终选 Sentino 是为了"workflow + tool + text/audio 流式同步在一处统一控制"的工程能力，不是工具/语音中转。这条事实强化了 Sentino 的差异化护城河 = Agent 工程层（含 TTS 调度和工具编排），不是单点中转

相关概念¶

• agora-rtc-voice
• ai-intelligent-agent
• voice-presence
• seal-architecture
• sentino-iot
• claude-agent-sdk — 评估后选择借鉴其 Agent Loop 设计，自建轻量实现
• harness-engineering — Agent Art 的工具化集成是 Harness 原则的应用
• agent-tool-design — Agent Art 自动生成 read_xx 工具的设计
• agent-runtime-architecture — 七层三链模型：自建 Agent Loop 的架构参照
• cloudflare-mesh — Agent Art 访问私有后端（数据库/API）的潜在网络方案
• sentino-memex — 自研长期记忆服务，Agent 平台的核心组件之一；yukai-agora-poc 是其首次对外白标客户战
• mem0 — 行业代名词与对比参照系，本平台主动以 Memex 替代而非接入
• google-memory-bank — 2026-04 新加入对照样本：与 Memex 同路线的 Google 托管版，对外定位锚点已扩到双对照（mem0 + Memory Bank）
• google-agent-platform — 2026-04-28 父概念页：Google 4 pillars × 18 组件全栈 Agent 平台是 Sentino 对外讲"我们也是 agent 平台"的必须对照参照系；Govern + Optimize 是 Sentino 当前缺失的两整柱
• 2026-04-28-memex-v2-design-options — Memex v2 设计选项评估：Memory Bank 4 个借鉴点工程拆解 + 排期建议（P1 必做 / P2 等触发 / P3 配套做）+ 反建议（核心瓶颈优先于借鉴点）
• yukai-agora-poc — 与 YUKAI Engineering 的陪伴机器人 PoC，是平台第一个对外白标交付项目
• hotmind-client — 家庭场景客户机会，Sentino 首次以 OpenAI 兼容 endpoint 形态对外（走传统 REST + function calling，客户 MCP server 不消费）
• agora-convoai-join-api — Agora ConvoAI v2 join API 完整字段集；Sentino 标准接入配置 vendor=custom + style=openai；MCP 渗透到 LLM 配置层进一步明确 Sentino 差异化护城河 = Agent 工程而非工具中转
• ai-first-engineering — CREAO 同规模同赛道对照样本：六边形战士 / Marketplace 决策 / 三层 Memory / 环境稳定 50→90 / AI-first 自检命题
• pivot-speed-as-moat — Sentino 双网关分裂等待决策不能无限期搁置的判断框架来源
• ai-economy-vs-human-economy — Sentino 同时押两个对角象限（IP 玩偶 + Agent 平台）的战略框架
• process-data-vs-output-data — Agent Art 长期资产沉淀视角：执行过程的工具调用序列、中间判断、回退点是真护城河载体，不是 latest 输出
• work-experience-ownership — 给企业客户卖"创建 Agent Art"时需前置回答"客户员工写出的 agent prompt + 工具配置归谁"
• bottleneck-shift-output-to-review — 客户接入后产能拉高 → 审核成新瓶颈，影响商务定价模型选择（按辅助审核而非按 token 计费）
• amphiflow-pattern — Agent Art v2 演进的备选架构路径：默认 workflow + agent 兜底（节省 token + 提升稳定性，但增加架构复杂度 + 与"逃生工具"原则有张力）
• decision-execution-decoupling — 决策源解耦的架构原则：当前 Agent Art 假设 LLM 是单一决策源，amphiflow 提供另一种可能性
• observe-think-act-cycle — Agent Art loop 内在结构是 OTA，与七层模型 Layer 3 同源
• research-preview-pattern — Anthropic 三机制（Research Preview / Launch Room / 工程师 PM 融合）对 Sentino 横向客户线推进的具体借鉴可能；Cowork 给客户 briefing 自动生成的用例对 sentino-tenga / yukai-agora-poc / hotmind-client 客户对接环节有直接参考价值
• agent-creator-refiner-operator — Agent Art 当前主要是 Refiner 形态（把用户散落数据收敛成 latest），Operator 能力较弱——客户向"AI 替我办事"演进时需补强，与 amphiflow-pattern workflow 兜底架构天然契合，但需前置 Liability Wall 评估
• plg-sales-coordination — Kim Graves 视角对 Sentino 销售姿态的 5 条直接对照启示（PLG+Sales 协同 / 创始人销售参与 / 反向 ICP / AI 销售机器人边界 / 客户案例销售姿态）
• why-change-why-you-why-now — 三客户线（YUKAI / Hotmind / TENGA）销售推进的 4 Why 自检框架；TENGA "Why change + Why now 都未答"印证 2026-04-20 战略复盘"停止方案发散"判断
• cold-calling-revival — Sentino 当前未尝试 cold call 渠道，可能是被低估的差异化窗口
• manus-case-2026-04 — Operator 类应用面临的"跨境监管不可逆"新维度，对 Agent Art Operator 强化路径的前置约束
• singapore-washing — AI agent 公司退出叙事重写，对 Sentino Agent 平台远期估值环境的影响
• chinese-investment-security-review — 中国侧 AI 跨境投资管制完整机制，客户线涉中国 IP / 数据时的政策环境
• anthropic-openai-pe-jv-2026-05 — 2026-05-04 PE-anchored FDE JV 是 Sentino Partner Channel 路径同源逻辑的更大规模实例 + Operator 类法律责任结构的资本级参考
• forward-deployed-engineer — FDE 模式作为 enterprise AI 部署 capability 的参照
• pe-anchored-ai-distribution — Sentino 的 IP / 玩具行业实施伙伴生态是同源逻辑的不同规模实例
• ipo-valuation-dual-track — Sentino 远期估值环境的参照（如远期演进出"主体 + 服务子公司"两层结构）