把产品演进分成三段：定制交付、平台化、平台编排，分别对应「看山是山、看山不是山、看山还是山」。多数团队不是卡在第一重，而是停在第二重——抽象做得很整齐，却忘了回到使用者的视角。
Agent 平台产品设计过程中存在一类高频偏差：产品经理沿用需求定义阶段的穷举方法，逐条罗列业务场景，并以此作为平台设计的输入。该方法在需求定义阶段具有合理性，但在平台构建阶段会带来三类系统性代价——覆盖不可完备、维护成本递增、缺乏结构信息。 本文提出一条从场景到能力的抽象路径：以动作结构统一场景描述，以动词收敛压缩场景空间，以契约属性划分能力边界，并以"新增场景是否零新增能力"作为抽象是否完成的验收标准。在此基础上，给出平台级场景的判定标准，包括平台级场景应具备的六项特征、不具备平台化价值的场景类型，以及打样场景…
当 Skill 池膨胀到万级，模型上下文窗口装不下所有工具描述，"让 Agent 选对工具"就成了一个系统工程问题。本文梳理一套可落地的生产级方案——从 4 层漏斗架构、SkillRouter 论文实测数据、到置信度分流机制，完整走一遍。 一、核心矛盾：1 万个 Skill，模型看不过来 一个 MCP 工具的 schema 描述（名称 + 功能说明 + 参数定义）约 150 token。当 Skill 池达到 10,000 个，仅工具描述就需要约 150 万 token——远超当前主流模型的上下文窗口上限（128K…
A2UI (Agent-to-User Interface) 协议详解 A2UI 是一个开放的协议标准，让 AI Agent 能够安全地向客户端发送丰富的交互式用户界面。Agent 发送声明式 JSON 描述 UI 的意图，客户端使用自己的原生组件库渲染出来。 一、原始内容概述 1.1 什么是 A2UI A2UI（Agent-to-User Interface）是一个开放的协议标准，由 Google 主导开发，CopilotKit 及开源社区共同贡献，Apache 2.0 许可。它的核心使命是：让 AI Agent…
Hermes-Agent 源码架构分析报告 1. 项目总览 指标 数值 Python 文件总数（排除测试） 822 Python 代码总行数（排除测试） ~589,563 核心模块数 9 模型提供方（providers） 29 个插件目录 内置技能（skills） 18 个分类目录 可选技能（optional-skills） 19 个分类目录 支持的消息平台 20+ 核心模块：agent / hermes_cli / plugins / gateway / tools / acp_adapter / tui_gat…
概述 ArkClaw 是火山引擎（字节跳动）于 2026 年 3 月推出的云 SaaS 版本，基于开源项目 OpenClaw（"龙虾"）构建。本报告从架构设计、安全体系、运行机制、多智能体、飞书集成及企业版等维度，全面剖析 ArkClaw 的技术内核。 产品定位与核心架构 ArkClaw 采用 Gateway-Agent-Workspace 三层架构，是开源 OpenClaw 的云原生 SaaS 封装。 Gateway 网关层 Gateway 层是所有用户请求的入口，负责协议转换与消息路由，核心职责包括： 协议转换…
Hermes Agent 核心策略全景 Hermes Agent 核心策略全景 1. 智能体分配策略 策略类型 触发条件 关键参数 行为描述 用户视角触发例子 子智能体委派 模型调用 delegate_task 工具 最大并发: 3, 深度: 1层, 迭代上限: 50 ThreadPoolExecutor 并行子 AIAgent，每个独立迭代预算，默认工具集 [terminal, file, web] 你说"帮我同时调研3个竞品"，助手派出3个小助手分头去查，各自独立工作 后台审阅 每回合结束后自动 spawn m…
本文档展示了用户与 AI Agent 在不同交互场景下的完整时序流程，涵盖 6 个核心参与主体，并按照「计划生成 → 工具调用链路 → 结果生成与返回」三阶段进行拆解。 参与主体 User（用户）：消息、语音、多模态输入的发起者 Agent（智能体工程）：编排、路由、决策的核心调度层 LLM（大模型）：意图识别、内容生成、语音合成等 AI 能力提供者 Agent Skills（技能系统）：封装特定领域能力的模块 MCP（中间层）：模型上下文协议，统一管理外部工具调用 Tools（外部工具）：各类第三方服务与 API…
Multi-Agent 架构使用判断框架 Anthropic 的核心立场 大多数团队不需要 Multi-Agent 系统。在单个 Agent 上反复改进 prompt，效果可匹配花数月搭建的复杂多 Agent 架构，且代价更低。普通 Agent 消耗约 4 倍于聊天的 token，而 Multi-Agent 系统消耗约 15 倍，额外开销来自跨 Agent 的上下文复制、协调消息和结果汇总，因此需任务价值足够高才能覆盖开销。 该使用 Multi-Agent 的场景 上下文污染 不同子任务积累的信息互相干扰导致推理质…
上下文工程的本质 大模型推理时的信息来源仅包括参数知识（训练阶段获得，推理阶段不可改）和上下文窗口内容。上下文工程本质是构建大模型的工作记忆，决定其决策时能看到的信息，进而影响行为质量。 与 Prompt Engineering 的区别 Prompt Engineering：关注措辞、格式、few-shot 示例等 “怎么说” 的问题。 上下文工程：关注每轮推理时上下文窗口中 “看到什么”，包括信息的选择、结构排列。 核心差异：Agent 是多轮推理循环（典型任务平均调用 50 次工具），上下文信息不断累积，存在 …