Agent Harness 手册

外观

本页含时效性内容，数据截止于 2026-08；JD、价格、产品功能等信息可能已变化，引用前请核对原始出处。

案例：扣子（Coze） ​

字节跳动出品的一站式 AI 智能体（Bot）开发平台：海外版 Coze 于 2023 年 11 月上线试水，国内版「扣子」2024 年 2 月 1 日正式发布（InfoQ 对扣子负责人的访谈）。用户不写代码，在可视化界面里编排提示词、插件、工作流、知识库，搭出一个 Bot，再一键发布到豆包、飞书、微信等渠道。

本站前面的案例——Claude Code、LangGraph、SWE-agent——讨论的都是「给开发者用的 harness」：harness 是代码，是你可以 fork、魔改、部署的软件。扣子代表另一个物种：harness 本身被做成了 SaaS 产品。你在组件章读到的每一个概念——循环、工具、记忆、规划、子代理、权限——在扣子里都对应一个看得见、点得着的产品功能。它因此成为观察「harness 概念如何产品化」的最佳样本。

本文的论点：扣子是把 harness 设计空间整体「降维」成图形界面的一次尝试——它换来了前所未有的低门槛，代价是把决策权从开发者手里收走，交给了平台预设的菜单。 这个交换在客服、营销、办公自动化这类场景极其划算，在开放任务上则迅速触顶。

一份「可以点」的组件目录 ​

读扣子最好的方式，是拿Harness 的解剖的组件清单逐项核对。几乎每一项都有对应的产品功能：

Harness 组件扣子里的形态本站对应章节
提示词 / 人设编排面板的「人物设定与回复逻辑」文本框上下文工程
工具系统插件商店（官方 + 第三方插件）、自定义插件工具系统
规划工作流（人工预设流程）+ 单 Agent 的自主循环规划与任务分解
知识库（RAG）上传文档 → 自动分段、向量化、召回测试记忆系统
记忆变量、数据库（结构化表）、长期记忆库三档记忆系统
子代理多 Agent 模式：画布上连接多个 Agent 节点子代理
循环单 Agent 模式内置的对话-工具调用循环Agent 循环
观测试运行面板、运行详情、Coze Loop（罗盘）评测平台可观测性
权限 / 发布渠道审核、团队空间协作、API 鉴权权限与人机协作

Coze Studio 的开源 README 里有一句很能说明设计意图的话：在扣子中，工作流、插件、数据库、知识库、变量被统称为「资源（resources）」——也就是说，这些在代码型 harness 里是架构决策的东西，在扣子里被统一抽象成「可以创建、管理、挂载的资产」。这是平台化的核心动作：把架构问题变成资产管理问题。

三种控制流：工作流、单 Agent、多 Agent ​

扣子的编排能力可以分成三档，恰好对应规划章里控制流自由度由低到高的光谱：

1. 工作流（Workflow）—— 人画的 DAG。 可视化画布上拖拽节点：大模型节点、插件节点、代码节点（支持 JavaScript/Python）、知识库检索、条件分支、循环。流程完全由人定义，模型只在 LLM 节点内部做理解和生成。这是 Anthropic 所说的「workflow」一极，也是扣子处理确定性业务（信息收集表单、固定步骤的内容生产流水线）的主力形态。

2. 单 Agent —— 内置的自由循环。 默认模式：人设提示词 + 插件 + 知识库，模型自主决定何时调插件、何时查知识库、何时回复。平台不提供（也不暴露）循环的内部结构，你只能通过提示词和「插件何时触发」的自然语言描述去影响它。

3. 多 Agent 模式 —— 路由 + 分工的图。 官方文档描述：在画布上添加多个 Agent 节点并连接，每个节点有独立的提示词、插件和工作流；「开始」节点根据用户输入和各节点的适用场景描述把任务分发下去（扣子官方文档：多 Agent 模式）。本质是 supervisor 路由模式的可视化版本——和 LangGraph 的图异曲同工，但节点间连线的语义是「任务移交」而非「状态流转」。

text
扣子的三档控制流（自由度递增，可控性递减）：

 工作流                    单 Agent                  多 Agent
┌─────────┐             ┌──────────┐            ┌──────────┐
│ LLM 节点 │             │  人设     │            │ 开始节点  │
│    ↓     │             │  prompt  │            │ (路由分发) │
│ 插件节点  │             │    ↓     │            └────┬─────┘
│    ↓     │             │ 内置循环  │                 │ 按"适用场景"
│ 代码节点  │             │ ↓      ↑ │            ┌────┴────┐
│    ↓     │             │ 插件调用  │            ▼         ▼
│ 条件分支  │             └──────────┘         Agent A   Agent B
└─────────┘              平台管循环，           （独立人设/插件/工作流）
 人定流程                你只管人设               模型决定移交给谁

一个值得注意的缺位

三档里没有 Claude Code 那种「模型自己维护 todo list、自己决定步数上限」的交织式规划。扣子的 agent 在单次对话内循环，但跨会话的规划状态、可审批的计划工件并不在产品菜单上。低代码平台倾向于把「任务结构」前置给搭建者画好（工作流），而不是留给运行时的模型即兴发挥——这与它的目标用户（非工程师）完全自洽。

插件、知识库、记忆：组件的产品化样本 ​

插件 = 工具生态的托管市场。 扣子把工具做成了插件商店：官方插件覆盖联网搜索、图像理解、文档处理等常见能力，第三方开发者也可以把自有 API 包装成自定义插件上架。对比 Claude Code 的工具哲学——「给模型 grep 和 bash，让它自己组合」——扣子是反方向的极端：每个工具都被封装成带表单参数的产品卡片，模型只需要填槽。这让工具调用的成功率对弱模型友好得多，但也意味着工具能力的边界就是商店的货架，货架上没有的，就要自己写代码包装。

知识库 = RAG 的一站式封装。 上传 PDF、网页、表格，平台自动完成分段、向量化、索引，提供召回测试面板；还分文本、表格、照片三种知识格式。组件章里「检索策略、分块大小、embedding 选型」这些工程决策，被压缩成几个开关。

记忆 = 三档显式产品。 变量（会话内的键值对）、数据库（结构化表格，模型可通过自然语言读写行记录，即官方所说的长期记忆的数据库存储能力）、长期记忆（新版记忆库，按用户 UID 隔离存储与召回，见官方文档）。这三档对应记忆章里「工作记忆 / 结构化状态 / 持久化事实」的经典分层——扣子大概是第一个把这套分层直接做成 GUI 的大众产品。

产品化的得与失

平台化封装对目标用户是巨大的善意：不会写代码的运营也能搭出带 RAG 和数据库记忆的客服 Bot。但同一动作对工程师是束缚——你无法换 embedding 模型、无法自定义重排、无法审查循环的提示词。「免配置」的另一面是「不可配置」，这是所有平台型 harness 的结构性取舍。

模型绑定与双版本：字节生态的纵向整合 ​

扣子的模型层是理解其商业逻辑的关键：

  • 国内版默认豆包系列模型（早期为自研云雀大模型），2025 年 2 月计费调整后，新建智能体和工作流默认使用「扣子平台通用的豆包系列模型」，如需火山方舟上的其他模型须手动开通切换（官方计费公告）。模型费用由平台统一出账，扣子是豆包/火山引擎模型的分发前端。
  • 海外版接入 GPT-4、GPT-3.5 等海外模型，发布渠道也换成了 Discord、Telegram 等国际平台（国内/海外版本差异）。国内版渠道则是字节自家生态优先：豆包、飞书、微信公众号/客服、抖音、掘金、小程序，外加 API 与 Chat SDK（发布相关报道、渠道梳理）。

发布渠道值得从 harness 视角多看一眼。代码型 harness 的「交付」是部署脚本；扣子的交付是渠道绑定——Bot 搭好后一键出现在豆包 App、飞书群聊或微信公众号里。对业务方来说，harness 的最后一公里（触达用户）被平台消灭了；对平台来说，这也是把开发者锁进字节分发体系的钩子。

收费模式：为「调用次数」而非「席位」付费 ​

扣子的商业化是典型云厂商打法（官方计费公告、火山引擎专业版控制台）：

  • 基础版免费但限额度，面向个人尝鲜；
  • 专业版按量后付费：智能体调用 0.002 元/次、知识库 10GB 内免费、模型 token 按豆包定价计，另加每日 500 资源点的免费额度（当日有效），统一用「扣子资源包」抵扣；
  • 计费主体分离：使用扣子官方模型的智能体发布到商店后，消耗由使用者承担，开发者不为自己的用户买单——这是典型的平台补贴供给侧、做大生态的策略；
  • 海外版则是面向个人开发者的订阅积分制（Premium lite / Premium / Premium plus 档位，见深度剖析字节 Coze/扣子）。

2025 年 7 月 26 日，字节进一步把核心引擎开源：Coze Studio（开发平台）与 Coze Loop（罗盘，prompt 调试与评测平台）以 Apache 2.0 协议放上 GitHub，后端 Golang、前端 React + TypeScript，工作流画布基于开源的 FlowGram 引擎，Agent 运行时基于 CloudWeGo 的 Eino 框架，最低 2 核 4G 可本地部署。开源回答了「平台型 harness 怕被锁定怎么办」的问题——你可以把整套低代码 harness 抱回自己机房。

平台型 vs CLI 原语型：设计空间的两极 ​

把扣子和 Claude Code 并排，能看到 harness 设计空间最宽的一段光谱。两者都是「成功的 agent 产品」，但对同一个问题给出了相反答案：

维度扣子（平台型）Claude Code（CLI 原语型）
harness 的存在形式托管 SaaS，GUI 配置本地进程，代码 + 文本文件
用户是谁运营、产品经理、小商家工程师
控制流人画工作流 / 内置循环 / 多 Agent 图一个主循环，模型全权
工具插件商店，表单填槽grep/bash 等 Unix 原语
记忆变量/数据库/记忆库，GUI 管理一个 Markdown 文件
模型平台绑定（豆包），弱可替换自家模型但 harness 与模型分层
扩展边界自定义插件、代码节点、API整个 shell 生态、MCP、hooks
分发渠道一键发布（豆包/飞书/微信）无分发层，嵌进 CI/脚本
失败时的调试试运行面板看节点输入输出看轨迹、改提示词、改代码
能力天花板平台菜单模型能力 × 用户想象力

这张表的分歧可以归结为一个选择：复杂度由谁承担。扣子把复杂度收进平台（内部处理检索、循环、记忆），用户看到的是菜单；Claude Code 把复杂度让给模型和用户，产品保持极薄。前者赌「绝大多数需求是模板化的」，后者赌「开放任务的价值更高，且模型会越变越强」。

低代码 harness 的天花板在哪

从扣子的形态能清楚看到三道天花板。其一，开放任务不可表达：工作流要求你能预先画出流程图，而「帮我调研这个选题」「修好这个 bug」这类任务根本没有图——这和 LangGraph 案例里讨论的困境相同，只是低代码把它放大了。其二，调试深度受限：当 Bot 行为不符合预期，你能调的是提示词和开关，看不到循环内部——黑盒面积远大于代码型 harness。其三，模型红利吃不满：平台绑定模型与封装意味着新模型的原生能力（更长的上下文、更强的自主规划）要等平台改造菜单才能释放，而薄 harness 几乎即时受益（这正是模型 vs. Harness讨论的动态问题）。字节自己的应对耐人寻味：2025 年 4 月推出「扣子空间」（通用型自主 Agent，对标 Manus 的形态，产品迭代时间线），且平台在 2025 下半年后的 2.0/3.0 版本持续向「自主完成长期任务的 Agent」方向演进（扣子版本功能盘点）——在模板化平台之外另开自由 agent 产品线，等于官方承认了天花板的存在。

判断框架：什么时候平台型 harness 是对的 ​

Q1. 搭建者会写代码吗？
    ├─ 不会 / 不想 ──────────────→ 平台型是唯一现实选项
    └─ 会，且任务开放 ───────────→ 代码型 harness 上限更高

Q2. 任务的流程能事先画出来吗？
    ├─ 能（客服、表单、流水线）──→ 工作流：可控、可审、便宜
    └─ 不能（调研、编程、探索）──→ 自由 agent，别硬套平台

Q3. 你需要触达终端用户的渠道吗？
    ├─ 需要（豆包/飞书/微信生态）→ 平台的分发价值 > 锁定成本
    └─ 不需要（内部工具/CI）─────→ 自建 harness + API 更自由

Q4. 数据合规与私有化是硬要求吗？
    ├─ 是 ──────────────────────→ Coze Studio 开源自部署，或自建
    └─ 否 ──────────────────────→ 托管 SaaS 省事

反模式也同样清晰：不要因为在扣子上能搭出来，就把开放任务硬塞进工作流——你会得到一个几十个节点、处处是「LLM 兜底分支」的怪物，维护成本远超直接写代码。平台上的成功案例几乎都是「流程确定性高 + 分发渠道刚需」的组合，这不是巧合。

延伸阅读 ​

参考资料 ​