HumanLayer:从人工审批 SDK 到多人协作编码 Agent 云平台

AI
Agent
Human-in-the-Loop
开源
审批
协作
2026/10/22
·

阅读时间: 大约 14 分钟

HumanLayer:从人工审批 SDK 到多人协作编码 Agent 云平台

函数风险分级:safe(只读公开数据、联系本人,1x)、medium(读私有数据、严格规则沟通,约10x)、danger zone(代我发声、篡改/销毁数据,100x)

HumanLayer 最初是一个给 AI Agent 加”人工审批”的开源 SDK:用装饰器把高风险函数包起来,执行前强制找人确认,被拒绝时把反馈回传给模型;另一个原语 human_as_tool() 让 Agent 主动向人类求助。项目方随后把产品重心转向商业的”多人协作编码 Agent IDE + 云”。本文基于 PyPI 上的 SDK 包、GitHub 仓库与现行官网一手资料,分别梳理两代形态,并写明官方自己标注的 deprecated 口径。

一、背景:工具调用越有用,风险越高

Agentic 工作流的核心是 function calling:LLM 通过工具与外部世界交互。HumanLayer 在 README 中给出的判断是——最有用的函数恰恰风险最高:公开数据检索、给作者本人发进度消息属于低风险;读取私有数据、按硬编码模板沟通属于中风险;代本人/公司发邮件、发社交内容、写 CRM、改计费与开关属于高风险。即使模型推理与提示路由做得再好,“90% 准确率”在高风险函数上不可接受,更何况模型会幻觉、会生成明显 AI 腔的文本。

官方把函数按影响量级画成三级:safe(1x)、medium(约 10x)、danger zone(100x),审批闸门应加在中高风险层。

二、第一代:开源 HITL SDK 的两个人机原语

PyPI 包 humanlayer(调研时版本 0.7.9,要求 Python >=3.10,<4.0,Apache-2 许可,另有 npm 包 @humanlayer/sdk)提供两个原语:

1. @hl.require_approval() 装饰器——执行前拦截。 被装饰的函数(如”代我发邮件”)在 Agent 调用时不会立刻执行,而是先把请求发给人类审批;批准才执行,拒绝时把拒绝理由作为反馈回传给 LLM,让模型据此修改而不是直接崩溃。关键设计主张是:审批逻辑烘焙在工具/函数自身里,而不是靠上层提示词自觉,因此”即使 LLM 出错或幻觉,人工 oversight 仍然确定性地生效”。

require_approval 装饰器包住"Communicate on my behalf"高风险函数

2. hl.human_as_tool()——Agent 主动求助。 把一个”联系人”暴露成工具,Agent 在调试、征求建议、需要人对草稿表态时可以主动发起对话,而不只是被动等待审批。

触达渠道(Omnichannel Contact):CLI、Slack、Email,路线图中列有 Discord;支持把审批粒度路由到指定团队或个人(Granular Routing)。由于实现位于工具层,官方称可配合任意 LLM(OpenAI、Claude、Llama 等)与主流编排框架,仓库示例覆盖 LangChain、CrewAI、ControlFlow 与裸 OpenAI Client。

三、理论框架:Gen 2 助手与 Gen 3 outer-loop Agent

SDK README 把 LLM 应用划分为三代:Gen 1 聊天(人发起问答);Gen 2 Agentic Assistants(框架做提示路由、工具调用、思维链与上下文管理,仍由人单次发起任务);Gen 3 Autonomous Agents 运行在”outer loop”,自己驱动目标、自己调度成本,人—Agent 沟通变为 Agent 主动发起。

Gen 2 规划-执行-评估闭环 vs Gen 3 outer-loop:call tool 可走向 human approval 或 human as tool,然后 continue or sleep

按这个框架,require_approval 对应”敏感操作的人工放行”,human_as_tool 对应”Agent 主动咨询”,二者共同服务于 Gen 3 自治 Agent 长时间运行时的监督需求。

四、第二代:多人协作编码 Agent IDE + 云

现行官网(humanlayer.dev / humanlayer.com 同一产品)已转向商业平台定位——“multiplayer coding agent workspace”,把 Agent session、计划类 artifacts(research.md、design.md、structure.md、mockup.html、plan.md)与代码 diff 聚合到一处,支持团队在设计文档上评论式打磨(comment-driven refinement),并可下钻到每条 thinking message、子 Agent 工具调用与代码改动。架构上本地 daemon 在笔记本上并行多个 session,可再拉起 cloud daemon 跑长任务,经 HumanLayer API 同步,Web/桌面/手机同一 UI,合盖后 Agent 继续工作。

定价(官网口径):

计划价格关键额度
Starter免费最多 3 名团队成员,每月最多 200 sessions
Pro$100/用户/月BYOK(Claude Code、Codex 等)、无限任务与 session、多仓 workspace 与 worktree、内联图表/mockup、artifacts 上实时人机协作、remote daemon
Enterprise定制SSO/SAML、审计日志、按量定价、定制条款、On-Prem / 私有 VPC

其他官方口径:BYOK 模式下不单独收 token 费,用户自带 Claude/Codex/Copilot/Fireworks 订阅或 API key;平台通过 SOC 2 Type II(Vanta 监控),ZDR 与 DPA 在企业档提供;团队同时维护开源的 RPI(Research-Plan-Implement)框架与更早的 “12 Factor Agents” context engineering 仓库,但主产品当时尚未开源(FAQ 原文:“Not yet, but we’ll be open-sourcing some building blocks”)。

五、必须写明的口径与局限

  1. SDK 仓库已被作者标记 deprecated:GitHub humanlayer/humanlayer 主页原文写明 the code here is pretty much all deprecated,建议改试重建版 humanlayer.com。PyPI 上的 0.7.9 仍可安装,但官方不再把它作为主线,新接入方应以现行平台为准。
  2. SDK 路线图大量处于 Beta/Alpha/Planned:Require Approval、Human as Tool、CLI、Slack、Email、LangChain、CrewAI 为 Beta;ControlFlow、GripTape、自定义响应选项为 Alpha;Discord 审批、SMS/RCS、Async/Webhook、LlamaIndex、Haystack、BYO server 的 Open Protocol 均为 Planned——这些能力没有全部交付。
  3. “确定性保证”的边界:require_approval 保证的是”函数执行前必经审批闸门”,不保证审批人判断正确,也不保证 Agent 不会在未被装饰的函数上出错;它是工程护栏,不是可靠性证明。
  4. 商业平台价格不含 token:$100/用户/月之外,模型费用走 BYOK 另计,TCO 需叠加 Claude/Codex 订阅。
  5. GitHub 11.7k stars、961 forks 是旧 SDK 仓库的历史积累(调研时页面自报),主要反映第一代 HITL SDK 的关注度,不能等同于现行商业平台的用户规模。

六、适用与不适用

适合(SDK 思路与现行平台分别看):

  • 自己用 LangChain/CrewAI 等框架搭 Agent、只想给”发邮件/改记录”这类函数加一道审批闸的开发者,可参考 require_approval 模式;
  • 多人团队并行跑 Claude Code/Codex、需要统一看 session、在设计稿上协作、并把任务长任务丢到云端 daemon 的工程组织,可评估现行平台;
  • 关注 outer-loop Agent 监督模式的研究者,其 Gen 2/Gen 3 框架划分有参考价值。

不适用:

  • 期待一个长期维护的开源 HITL 标准库直接上生产的团队(仓库已 deprecated,路线图多项未交付);
  • 预算敏感的个人开发者(Pro $100/用户/月为团队定价,免费档限 3 人 200 sessions/月);
  • 需要完全本地、无外部 API 的审批流(SDK 依赖 HumanLayer API 路由审批,自托管 Open Protocol 仍在 Planned)。

七、客观分析:优势与局限

优势:

  1. 问题抓得准:把”高风险函数必须人工放行”从提示词自觉下沉为工具层强制闸门,拒绝反馈回传形成闭环,思路被众多 Agent 框架借鉴;
  2. 概念分层清晰:stakes 三级模型与 Gen2/Gen3 划分便于团队给工具定权限等级;
  3. 第二代产品切中协作痛点:session、artifacts、diff 聚合 + 合盖续跑,回应了编码 Agent 从”单人对话框”走向”团队软件工厂”的需求;
  4. BYOK 与合规:不重复卖 token,SOC 2 Type II 与企业档私有化选项照顾了组织采购。

局限:

  1. 主线迁移造成文档割裂:旧 SDK 教程、示例与新平台不是一回事,新手容易混用;
  2. 开源承诺未兑现完毕:主产品未开源,deprecated 仓库与活跃商业版并存,长期可维护性依赖公司经营;
  3. HITL 已成为通用件:Claude Code、各家框架内建审批/允许列表,SDK 的独特性被稀释;
  4. 价格档位偏高端:$100/用户/月 + BYOK token 费,对小团队不友好。

八、谁该关注

做 Agent 产品的工程师值得精读其 require_approval 装饰器设计与拒绝反馈闭环,把这套护栏模式移植到自有工具层;正在规模化使用编码 Agent 的团队可以把现行平台纳入”Agent 控制面”候选清单对比;纯开源自托管诉求则应等待其 building blocks 开源,或改用框架内建审批机制。

参考来源