Caspian 开源:Agent 转人工的 Tool 原语化,以及企业级人机协同工程新样本

2026 年 8 月 21 日,Dipanshu 和 Rushant 两位 Caspian 创始人在 Hacker News 发布《Show HN: Caspian – Talk to Human Tool for AI Agents》,6 分首页关注。两位创始人在帖里直接给出他们的关键洞察——"Most agent communication work is agent-to-human, no

2026 年 8 月 21 日,Dipanshu 和 Rushant 两位 Caspian 创始人在 Hacker News 发布《Show HN: Caspian – Talk to Human Tool for AI Agents》,6 分首页关注。两位创始人在帖里直接给出他们的关键洞察——"Most agent communication work is agent-to-human, not agent-to-agent. Protocols like A2A and ACP connect agents to each other; Caspian connects your agent to the people it works for, on the channels they already use."A2A / ACP 这类 agent-to-agent 协议在媒体上被讨论很多,但企业 AI Agent 实际产生的 communication 工作大部分是 agent-to-human——客服 Agent 要给用户回邮件、Sales Agent 要在客户用的 channel 上回 DM、Personal Assistant Agent 要把同一个对话 cross-channel 续起来。这条 insight 揭示了一个被严重低估的工程方向——把"agent 转人工"做成 tool 原语化 SDK,像 better-auth 抽象 auth、像 Stripe 抽象 payments 一样,把 agent-to-human 的 multi-channel communication 抽象成 single SDK integration。Caspian 用 declarative DSL + per-channel adapter + identity management 把 Slack/Discord/Telegram/Email/WhatsApp/Messenger 9 个 channel 统一处理,650+ tests across Python + TypeScript,hosted or self-host,把 1,500 行 channel plumbing 压成 cx.on_message / cx.handle / cx.tools 三个 tool call。结合同期 OneCLI / Talos / Warp / Decispher 等独立产品,这件事把企业 Agent 人机协同的工程化基线完整地勾出来。

## 一、Caspian 的核心问题定义

Caspian 创始人在 HN 帖和 GitHub README 里直接给出他们看到的 four pains——所有 agent team 都在 re-build 同样的四件事,任何一件都让 agent 变不 smart。

第一个 pain 是 infrastructure 你永远不想 own。"Writing the Slack bot is a weekend; owning it is forever."写 Slack bot 容易,own 永远——session/auth desync、reconnect loops、silent connection failures、payload changes on every platform version bump。这条洞察跟 Extensible-mcp / Warp / OneCLI 团队的观察一致——infrastructure 层的 pain 不是 build 时,是 maintain 时。Caspian 测了 42 个开源 agent project,发现 largest OSS agent frameworks 每个 maintain 25+ channel adapters in-tree,8-15% 的 issue tracker 全在 channel plumbing 上。这是行业级的人力浪费。

第二个 pain 是 communication 不是 agent decision-making 的 part。With one-off、per-channel integrations,a developer 决定 at build time where and how the agent talks。Agent 自己不能 reason 出"this deserves a quick Telegram ping now and an email summary afterwards"——每个 channel 都是 separate bot with separate code and separate identity。Communication 停留在 hardcoded plumbing,不是 capability the model can actually decide with。这条洞察跟 Warp 自进化 skill 设计呼应——Warp 通过 PR/code-review workflow 让 skill 改动走显式 review,Caspian 通过 declarative DSL 让 communication routing 由 model 决定。

第三个 pain 是 N identities for every one person。同一个人 DM 你的 agent 在 Instagram 今天,email 明天。你的 database 需要自己的"this is one person, one relationship, one running conversation"概念——who said what on which channel, what should happen next in the flow。每个 team 重新 build 这个 continuity layer per app,从来不停。这条洞察跟 Instinct 把对话状态存 S3 git bundle、Decispher 把 memory 分层一致——cross-channel / cross-session continuity 是企业 Agent 真正承担日常工作的前提。

第四个 pain 是 single-channel agent 是 competitive disadvantage。如果 competing agent 在 5 个 channel reachable,你的只在 1 个,users go where they get answered。开源 agent 数据显示 people actually rely on 的 agents are exactly the ones deployed across dozens of human channels — and that reach is exactly where their engineering efforts pile up。这条洞察是商业层面的——agent 能力边界不是 reasoning 能力,是 reachability。

## 二、Caspian 的核心架构

Caspian 的解法是 declarative DSL for communications + per-channel adapter + identity management,核心架构有四个关键设计。

第一个设计,channels are transports, not identities。Agent 是一个 program(message handler inspectable data),每个 channel 通过同一个 adapter interface bound,handler code 工作在 normalized model 上。Messages 到达时是 kernel events regardless of transport,overlap policies 序列化 concurrent chats。Slack/Discord/Telegram/Email/WhatsApp/Messenger 9 个 channel 都是 transport,不是 identity。同一个人在 multi-channel 上是同一个 thread,handler logic 不用关心 channel 差异。

第二个设计,declarative rules, one program。`@cx.on_message({"channel": "telegram", "command": "help"})` 一次性 filter channel、chat kind、command、overlap、instant ack。bot is data — declarative rules 是 inspectable + testable offline。这条设计对应 Talos 的 hardline → dangerous → effect 三阶段判定——declarative rules 比 imperative code 更可审计、可测试。

第三个设计,webhook verification always。Slack signing secret、Meta X-Hub-Signature-256、Telegram secret header、X CRC、signed email webhooks——mismatches rejected。这是安全底线,任何 channel adapter 都必须 enforce,而不是 optional。

第四个设计,hosted or self-host, same code。Default 走 Caspian gateway at api.trycaspianai.com,自托管用 CASPIAN_BASE_URL 自定义 endpoint,adapters 在你的 process 用你的 platform tokens。Switch modes without rewriting handlers。这条设计对应 machine0 的 Profile 注入 + Warp 的 open-source 模式 + Talos 的 sandbox default ——business model 和 self-host 必须共存。

## 三、Caspian 提供的工程能力

Caspian SDK 在 technical capability 层面提供六组核心能力。

第一组,multi-channel adapters。Self-host adapters ship in SDK for Slack / Discord / Telegram / Email / WhatsApp / Messenger / SMS / voice (Twilio)。Hosted mode 覆盖任何 channel the gateway supports(包括 Bluesky、Instagram、no local adapter 的 channel)。这是 build your own agent 想接 channel 时立刻省下的 1,500 行 plumbing。

第二组,model tools from same surface。cx.tools(thread) exposes Command catalog(post、react、send-photo、etc.) with schemas derived from kernel—— same API your handlers use。这条能力让 model 在 runtime 决定调哪个 channel 的什么 action,而不是 build-time hardcode。

第三组,per-channel packs in TypeScript。caspian-sdk/telegram / caspian-sdk/discord / caspian-sdk/slack 等 per-channel pack 让 parse/plan/execute 不拉整个 facade。这条设计对应 WARP self-improving skill 的 progressive disclosure——按需加载,context 精简。

第四组,socket inbound for Discord / Slack。cx.listen("discord") / cx.listen("slack") 在 held-open websocket(可选 extra),不需要 public URL。这条设计解决 agent platform firewall 友好性——大多数企业不允许 inbound public URL,socket-mode 是必要的 fallback。

第五组,offline fakes for every channel。Adapters consume each platform's payload shapes,650+ tests across Python + TypeScript,zero network in CI。这条设计对应 Argus Security 的 verifiable security testing、War p 的 PR/code-review workflow——testability 是 production-ready 的前提。

第六组,typing、streaming、rich sends。thread.post() 一次发出,thread.edit() 流式编辑,thread.send_media() 发图,thread.send_blocks() 发 rich blocks,reactions、pins、forwards、cold DMs 全部支持。这条设计对应 native platform 用户习惯——agent 必须 follow platform 习惯,不能只发纯文本。

## 四、把 Caspian 放进企业 Agent 人机协同的产品矩阵

把 Caspian 跟同期其他 Agent 通信/协同产品放在一起,可以看到企业 Agent 人机协同正在分裂成清晰的层次。

Agent-to-agent 通信层是 A2A / ACP 协议。Google A2A 2025 年 4 月发布,Linux Foundation 治理,定位 multi-agent 生态横向通信。这层解决 agent 之间的协作问题。

Agent-to-human 通信层是 Caspian。A2A / ACP 不解决这个问题,Caspian 给 declarative DSL + per-channel adapter + identity management,让 agent 主动 reach out 到 people。这层解决 agent 跟人类的协同问题。

Harness deterministic layer 是 OneCLI / Talos / extensible-mcp / AC2 / Warp / Machine0 / Decispher。这些产品各自解决 harness 层的不同问题(secret isolation、permission kernel、policy proxy、capability attestation、self-improving skill、persistent VM、shared knowledge)。

三层的分工清晰:Agent-to-agent 让多个 agent 协作,Agent-to-human 让 agent 跟人协同,Harness layer 让这两层都安全可审计。三个层次缺一不可,任何一层缺失都会让 Agent 平台在生产环境暴露问题。

## 五、企业 Agent 人机协同的具体 checklist

把 Caspian 的设计哲学映射回企业落地,可以列出一份具体 checklist。

第一条,Agent-to-human communication 必须 tool 原语化。任何 channel(Slack、Discord、Telegram、Email、WhatsApp、Messenger、SMS)必须通过 SDK adapter 调用,不允许 Agent 直接调 platform-specific API。直接调 platform API 是每次 channel 升级都会 break 的反模式。

第二条,任何 channel adapter 必须 declarative。Per-channel imperative code 应该被 cx.on_message / cx.handle / cx.tools 这类 declarative DSL 替代。Declarative 让 rules inspectable + testable + reviewable。

第三条,communication routing 必须 model-driven。Agent 在 runtime 决定调哪个 channel 发什么内容,build-time hardcode 是反模式。Model 看到的应该是"我需要 reach 这个人,通过他们最可能响应的 channel",而不是"build 时设定发 Slack"。

第四条,identity 是 first-class concern。同一个人在 multi-channel 上是同一个 thread,不是 separate bot。Handler logic 不需要管 channel,但 identity layer 必须管。

第五条,webhook verification 是 baseline,不是 optional。任何 channel adapter 必须 verify webhook signature,任何 mismatch 必须 rejected。这条是 security floor,任何 channel 不 enforce 都不能进生产。

第六条,hosted + self-host 两种 mode 必须等价。Hosted 走 vendor gateway 拿 billing, self-host 走 self-hosted gateway 拿 control,两种 mode 下 handler code 完全相同。

第七条,offline test 必须 zero network。任何 channel adapter 的 test suite 不应该调真实 platform API,必须用 offline fakes。这是 CI 可重复 + 隐私 + 性能保证。

第八条,model tools 必须暴露 thread-level capability。cx.tools(thread) 把 post、react、send-photo 等动作 expose 给 model,而不是 hide 在 SDK 内部。Model 必须能 reason about "我应该 react 这个消息"或"应该 send photo"。

第九条,socket-mode inbound 必须 available for blocked-port environment。Cx.listen 替代 public webhook,适配企业 firewall 严格只允许 outbound 的环境。

第十条,channel identity 必须按 person 不是按 channel。同一个人在 Instagram + Email + Slack 上的连续对话必须 shared thread。Single-channel bot 是 anti-pattern。

## 六、从 declarative agent 到 declarative communication

把这件事放到更大的图景里看,Agent 通信正在从 imperative 走向 declarative。早期 Agent 必须 imperative 调每个 platform API,每次 platform 升级都要重新适配。Caspian 这类工具出现后,Agent 用 declarative rule 描述意图("on telegram help command, reply with documentation"),runtime 决定具体怎么发。这跟 Warp self-improving skill 的 declarative rule 哲学是同一类——让 developer 写意图,让 runtime 决定实现。

接下来一年内,declarative communication 会和 declarative skill、declarative policy、declarative memory 一起成为 Agent 平台的标准组件。任何 vendor 缺这一块都会在 enterprise 落地时被快速淘汰——不是因为客户一定要 Caspian,而是因为客户一定要 declarative communication 这一层基础设施。

回到一开始的问题——Caspian 把"Agent 转人工"做成 Tool 原语化 SDK,像 better-auth 抽象 auth、像 Stripe 抽象 payments,把 1,500 行 channel plumbing 压成 3 个 tool call。剩下的是企业 IT 在落地时把十条 checklist 都做对,把 Agent 通信从 imperative hardcoded plumbing 升级为 declarative tool 原语化。这是 2026 年下半年 Agent 行业走向成熟的标志,也是企业 AI 真正能承担团队级协同工作的入场券。