导读

2026 年 5 月 28 日，Anthropic 扔下两颗重磅炸弹：

Claude Opus 4.8——在 Super-Agent、CursorBench、Legal Agent 等基准测试上全面超越 GPT-5.5，成为首个在 Super-Agent 测试中完成所有端到端任务的模型。

Dynamic Workflows——Claude Code 的新功能，让单个会话能并行运行数十到数百个子代理，自动规划、执行、验证、收敛，支持小时甚至天级别的复杂工程任务。

同一天，Anthropic 还宣布了 65 亿美元 H 轮融资、965 亿美元估值的消息，年化收入突破 470 亿美元。

这三件事放在一起看，不是一个巧合。Anthropic 正在构建的，是一套从模型能力到工程执行到商业规模的完整闭环。

一、Claude Opus 4.8：不只是更快，而是更”诚实”

1.1 速度提升 2.5 倍，成本反而更低

Opus 4.8 的 Fast mode 达到了 2.5 倍速度，同时比前代模型便宜 3 倍。多模态任务的 token 成本降低了 61%（据 Databricks 数据）。

定价保持不变：

这意味着什么？在同样的预算下，你可以让 Opus 4.8 处理 2.5 倍的工作量，或者用同样的工作量节省 60% 以上的成本。

1.2 编码能力的质变：从”能写代码”到”能发现代码里的问题”

Anthropic 官方给出的数据是：Opus 4.8 发现代码缺陷的概率比 4.7 低 4 倍。这不是说它会少犯错，而是它更不容易放过代码里的问题。

测试者的反馈很能说明问题：

“Claude Opus 4.8 的判断力明显更好。在 Claude Code 里，它会问正确的问题，抓住自己的错误，在计划不合理时提出质疑，并且在进行复杂的多服务探索之前先建立信心。”

“最大的区别是 Opus 4.8 倾向于主动标记分析的输入和输出中的问题，这是其他模型 routinely 会遗漏的。”

这种”主动质疑”的能力，是 AI 从工具向协作者进化的关键标志。

1.3 基准测试成绩

1.4 Effort Control：让用户掌控”思考深度”

Claude 4.8 引入了 Effort Control，用户可以在 Low → High（默认）→ Extra → Max 四个级别之间选择。

• Low：更快响应，更慢消耗 rate limit
• High：默认级别，平衡速度和质量
• Extra：适合困难任务和长时异步工作流
• Max：最高质量，最大 token 消耗

这个设计的巧妙之处在于，它把”思考时间”这个黑盒变成了用户可以显式控制的参数。对于简单任务，你不会为不必要的深度思考付费；对于复杂任务，你可以明确要求模型投入更多认知资源。

二、Dynamic Workflows：AI 工程的范式转移

如果说 Opus 4.8 是”更强的单兵”，那 Dynamic Workflows 就是”能指挥一个军团”的指挥官。

2.1 核心机制：规划 → 并行执行 → 验证 → 收敛

Dynamic Workflows 的工作流程分为五个阶段：

1. 动态规划（Dynamic Planning）：Claude 分析你的提示，将其分解为子任务
2. 并行执行（Parallel Execution）：工作分散到同时运行的子代理
3. 验证层（Verification Layer）：结果在整合前被检查，代理独立验证和反驳发现
4. 迭代收敛（Iterative Convergence）：工作流持续运行直到答案稳定
5. 状态恢复（Stateful Recovery）：进度自动保存，中断的作业无需重启

关键特性：协调发生在对话之外，所以无论任务规模多大，计划都能保持正轨。

2.2 使用方式

在 Claude Code 中，启用 auto mode 后，输入：

ultracode

或者直接让 Claude 创建一个工作流。

注意：Dynamic Workflows 消耗的子代理 token 远超普通会话，建议从有范围的任务开始测试。

2.3 真实案例：Bun 从 Zig 到 Rust 的移植

Jarred Sumner（Bun 作者）使用 Dynamic Workflows 完成了 Bun 的 Zig → Rust 移植：

工作流分解：

1. 映射阶段：一个工作流识别了 Zig 代码库中每个结构体字段的正确 Rust 生命周期
2. 移植阶段：数百个代理将 .zig 文件行为一致地移植为 .rs 文件，每个文件有两个审查员
3. 修复循环：迭代构建和测试套件，直到两者都干净运行
4. 优化：夜间工作流消除了不必要的数据拷贝，为最终审查打开 PR

“虽然尚未投入生产，但所有这些都是由 Dynamic Workflows 处理的。”

这个案例的意义远超技术层面。它证明了一件事：AI 不仅能写代码，还能管理复杂的、需要多轮验证和协调的工程迁移。

2.4 企业用户反馈

Klarna：

“我们在大型代码库中使用它识别死代码和发现传统静态分析遗漏的清理机会，帮助工程师更快地进行维护和重构工作。”

CyberAgent：

“从计划到实现一气呵成，我们可以信任更长时间的运行而不会失去可见性。”

三、65 亿美元融资：Anthropic 的”算力军备竞赛”

3.1 融资细节

领投方：Altimeter Capital、Dragoneer、Greenoaks、Sequoia Capital

hyperscaler 承诺：150 亿美元（包括亚马逊 50 亿美元）

3.2 算力布局

Anthropic 正在构建一个庞大的算力网络：

Claude 已成为首个在三大云平台（AWS、Google Cloud、Azure）都可用的前沿模型。

3.3 资金用途

1. 推进安全性和可解释性研究
2. 扩展计算能力以满足不断增长的 Claude 需求
3. 扩展产品和合作伙伴关系

CFO Krishna Rao 的表态很明确：

“Claude 对我们不断增长的全球客户社区来说越来越不可或缺，我们不懈努力使 Claude Code 和 Cowork 等工具更有帮助、更强大、更能适应他们的需求……这笔资金将帮助我们服务我们正在经历的历史性需求，保持在研究前沿，并将 Claude 带到更多工作发生的地方。”

四、技术深度：Dynamic Workflows 的架构启示

4.1 为什么这是范式转移？

传统的 AI 编程助手是”单轮对话”模式：你给提示，它给回答，一轮结束。即使有多轮，也是串行的。

Dynamic Workflows 引入了三个关键变化：

并行化：不是等一个子任务完成再开始下一个，而是同时启动数十到数百个子代理。

验证层：不是盲目相信每个子代理的结果，而是有独立的验证机制。在 Bun 的移植案例中，每个文件有两个审查员。

状态持久化：长时任务可以中断、恢复，不会因为会话超时或网络问题而丢失进度。

4.2 与现有工具的比较

4.3 对开发者的实际意义

短期（现在-6个月）：

• 大型重构和迁移项目可以显著加速
• 代码审查可以引入 AI 作为”预审查员”
• 遗留代码的理解和文档化成本大幅降低

中期（6-18个月）：

• “AI 原生”的开发流程会出现，代码库设计会考虑 AI 并行处理的能力
• 团队结构可能变化： fewer 纯编码人员，more AI 工作流设计师

长期（18个月+）：

• 软件工程的本质可能从”写代码”转向”定义问题和管理 AI 工作流”
• 代码库的生命周期管理（创建、维护、迁移、退役）大部分由 AI 自动化

五、LLM Smells：当 AI 写作成为”气味”

在 Hacker News 上，一篇名为《Various LLM Smells》的文章获得了 88 分和 50 条评论。作者分享了一个有趣的观察：

“去年我开始写数学博客，决定用 LLM 来润色/增强我的写作。LLM 生成的写作明显比我自己的好得多。词汇更丰富，句子结构更有趣等等。我发誓当时它看起来不像 AI 垃圾。然后大约 3 个月后，我在整个互联网上看到了完全相同的句子结构。”

作者收集了一些典型的”AI 气味”：

写作层面：

• 太多 punchline：”Humans trust symmetry because it feels like intelligence made visible.”
• 连续短句：”Yet the tilt is not an accident. It is the shape of the optimum.”
• “X is the Y of Z” 结构
• “not just X, it’s Y” 结构

网站设计层面：

• JetBrains Mono 字体
• 步骤和项目符号的固定布局
• 特定的按钮样式
• 卡片设计
• 闪烁点的 badge 组件

这个现象提醒我们：当 AI 生成的内容达到一定密度，它会创造出一种可识别的”风格”，而这种风格会迅速从”新鲜”变成”陈词滥调”。

对于内容创作者来说，这意味着什么？

1. AI 是起点，不是终点：用 AI 生成初稿，但必须注入个人视角和独特表达
2. 警惕”AI 最优解”：AI 倾向于生成”安全”的内容，但安全往往意味着平庸
3. 风格即品牌：在 AI 时代，独特的声音比完美的语法更有价值

六、行业影响：AI 正在重新定义”编程”

6.1 从”写代码”到”管理代码”

Dynamic Workflows 的出现，标志着一个转折点：AI 不再只是辅助写代码的工具，而是可以管理整个代码库的工程伙伴。

Bun 的移植案例是一个极端但有力的证明：75 万行代码，11 天，99.8% 测试通过率。这不是”AI 写了点代码”，而是”AI 管理了一个完整的工程迁移项目”。

6.2 开发者角色的演变

未来的开发者可能需要掌握的新技能：

• 工作流设计：如何分解复杂任务，定义子代理的边界和验证规则
• AI 协调：如何管理数百个并行代理的冲突和依赖
• 质量守门：在 AI 自动验证的基础上，定义人类最终审查的节点

6.3 竞争格局

Anthropic 这一轮操作（Opus 4.8 + Dynamic Workflows + 65 亿融资）形成了对 OpenAI 的强力挑战：

七、写在最后

Claude Opus 4.8 和 Dynamic Workflows 的发布，加上 65 亿美元融资，构成了 Anthropic 在 2026 年中期的”三连击”。

这不仅仅是产品更新，而是一个信号：AI 正在从”工具”进化为”协作者”，从”单任务”进化为”项目管理”，从”辅助人类”进化为”与人类共同主导”。

对于开发者来说，最实际的启示可能是：开始思考你的工作中哪些部分可以被”工作流化”——分解为可并行的子任务，定义验证规则，让 AI 处理执行，你专注于定义问题和判断结果。

因为当 AI 能并行运行数百个子代理时，真正的瓶颈不再是执行速度，而是你如何定义问题、如何设计验证机制、如何在 AI 的输出中识别真正的洞察。

参考链接：

• Claude Opus 4.8 官方发布
• Dynamic Workflows 介绍
• Anthropic Series H 融资公告
• Various LLM Smells

深度研究智能体的生产级架构：来自 Thoughtworks 的实战复盘

背景：为什么深度研究如此困难

一款新药从立项到上市，平均成本 26 亿美元。其中约 50% 的研究是在没有充分证据支撑的情况下开展的——不是没有知识，而是知识分散在无数孤岛中，无法被及时获取和连接。

Sarang Kulkarni 在 Thoughtworks 的团队面临的核心挑战正是这个：如何构建一个系统，让研究人员能够跨内部数据和互联网数据进行发现、连接和推理，同时保证可靠性、透明度和合规性？

这是一个典型的深度研究（Deep Research）场景，也是一个典型的多智能体系统设计难题。

从 RAG Chatbot 到 Agentic RAG++：三阶段演进

Kulkarni 团队没有一开始就上大模型，而是采用了渐进式架构演进：

这种演进路径值得大多数团队借鉴：不要在第一阶段就设计过度通用的架构，复杂度要随问题复杂度增长。

核心架构：三环系统

深度研究系统的核心是一个三环架构：

┌──────────────────────────────────────────────────────────────┐
│                    深度研究系统                               │
├──────────────────────────────────────────────────────────────┤
│  1. 澄清环（Clarification Loop）                               │
│     → 初始查询细化，理解用户真正想问什么                        │
│                                                              │
│  2. 研究环（Research Loop）                                   │
│     → 思考/规划 → 执行 → 反思（Inspect） → 更新（Update）       │
│                                                              │
│  3. 写作环（Writing Loop）                                    │
│     → 写作 → 反思（补全研究阶段遗漏的内容）                    │
└──────────────────────────────────────────────────────────────┘

研究环的四个步骤

研究环是这个架构最核心的部分，包含四个严格顺序的步骤：

1. Think & Plan — 研究之前的推理规划
2. Execute — 执行研究任务（检索、爬取、API调用等）
3. Inspect — 研究之后的输出验证
4. Update — 生成最终报告

这里的关键设计是将推理暂停（Think）和反思（Inspect）显式化为独立步骤，而不是让模型在同一个上下文中边想边写。

为什么需要写作环

研究环完成后，写作阶段可能遗漏一些研究阶段已经获取的信息。写作环通过二次反思来补全这个缺口：

“任何在研究中已获取但写作任务没有捕捉到的信息，都会在重新起草步骤中被补充完整。”

这相当于给研究系统加了一个双向验证层：研究结果要经得起写作的检验，写作内容要忠实于研究发现。

工具设计：RAG 和 SQL 的工程细节

RAG 工具的混合检索策略

• 加权混合搜索（Weighted Hybrid Search）
• 初始检索 20 个上下文块
• 通过重排序（Re-ranker）精炼至 7 个最终上下文块

这个”20→7”的压缩比设计很关键：保留足够信息密度，但过滤掉噪声。

text2sql 工具的错误反馈机制

让 LLM 执行 SQL 查询时，最难处理的是错误修正。Kulkarni 团队的方案是将 SQL 执行错误反馈给 LLM，形成一个错误→反思→修正的闭环：

SQL 执行失败 → 错误信息回传给 LLM → LLM 生成修正版 SQL → 重新执行

这类错误反馈机制在所有工具调用场景中都适用，本质上是让模型在”做中学”。

关键挑战与应对策略

上下文焦虑（Context Anxiety）

当上下文中信息量过大时，模型的推理质量反而下降——这被 Kulkarni 称为”上下文焦虑”。应对方法是精确的上下文选择和压缩，而不是简单增加上下文窗口大小。

双重反思机制

反思不仅是数据反思（输出的信息是否准确），还包括过程反思（执行过程是否完整，是否还有遗漏步骤）。

Harness 工程：模型之外的另一半

Kulkarni 提出了一个核心观点：

AI 智能体 = 模型 + Harness（驾驭系统）。模型越强，Harness 可以越薄。

Harness 包含：工具设计、记忆系统、验证检查、约束条件和反馈回路。Harness 工程的最终目标是让自主智能体更可靠、更可问责。

这个观点对国内做 AI 应用落地的团队有重要启示：不要把所有精力放在模型选型和 Prompt 调优上，工具和反馈机制的设计往往比模型本身更重要。

关键经验总结

1. 从简单开始：RAG 对基础查询有效，随着复杂度增加再引入智能体架构
2. 多环架构提供结构：澄清→研究→写作的三环为复杂研究提供了清晰的执行框架
3. 反思机制不可或缺：数据反思和过程反思双重机制确保输出质量
4. Think-Act 循环是关键：长周期任务需要在执行中嵌入显式的推理暂停
5. Harness 工程很重要：工具设计、记忆系统和验证机制决定了智能体的可靠性上限
6. 上下文管理是瓶颈：上下文焦虑会直接导致推理质量下降，需要精细化的上下文压缩策略

本文是对 InfoQ 文章《Sarang Kulkarni on Lessons from Building Deep Research Agents in Production》的深度解读，更多详情可阅读原文。

Kubernetes v1.36 的发布标志着这个云原生编排平台正在经历一次重要的范式转变——从”灵活框架”走向”有主见的默认配置”。本次release包含 70 项增强（18 项 Stable、25 项 Beta、25 项 Alpha），核心聚焦三大方向：安全加固、AI/ML 工作负载成熟化、以及大规模集群的 API 可扩展性。

本文将深入解读其中对工程师日常影响最大的几个关键特性。

一、安全默认收紧：从”可选”到”必须”

1.1 User Namespaces 正式 GA

这是容器安全领域的一个里程碑。User Namespaces 将容器内的 root 用户映射到宿主机上的非特权用户，意味着即使进程成功逃逸容器，也无法获得宿主机的管理员权限。

# 启用 User Namespaces 的 Pod 配置示例
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  hostUsers: false  # 启用 user namespace
  containers:
  - name: app
    image: nginx:latest

此前，容器逃逸往往意味着直接获得宿主机 root 权限。User Namespaces 的 GA 让”纵深防御”从最佳实践变成了默认行为。

1.2 Mutating Admission Policies 替代 Webhook

传统上，自定义准入控制需要维护独立的 webhook 服务器，带来额外的延迟和运维复杂度。v1.36 引入的 Mutating Admission Policies 使用 CEL（Common Expression Language）直接在 Kubernetes 原生对象中定义策略，无需额外的 webhook 基础设施。

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: enforce-security-context
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations: ["CREATE"]
  mutations:
  - patchType: "ApplyConfiguration"
    applyConfiguration:
      expression: |
        {
          "spec": {
            "securityContext": {
              "runAsNonRoot": true,
              "seccompProfile": {"type": "RuntimeDefault"}
            }
          }
        }

这一变化对于需要严格安全合规的企业环境意义重大——策略执行不再依赖外部服务的可用性。

1.3 细粒度 Kubelet API 授权

过去，访问 kubelet API 需要宽泛的 nodes/proxy 权限。v1.36 引入了精确的、最小权限的访问控制，遵循零信任架构的原则，将权限粒度细化到具体的 API 端点。

1.4 SELinux Volume Labeling 优化

传统的递归文件重标记（chcon -R）在大型卷上可能导致显著的 Pod 启动延迟。v1.36 改为在挂载时直接应用正确的 SELinux 标签：

mount -o context=system_u:object_r:container_file_t:s0:c123,c456 /dev/vdb /mnt/data

这一改动将 SELinux 强制启用系统上的 Pod 启动时间从秒级缩短到毫秒级。

二、AI/ML 工作负载：从”能跑”到”跑好”

2.1 DRA（Dynamic Resource Allocation）增强进入 Beta

AI 工作负载对 GPU 等加速器的调度需求与传统应用截然不同。v1.36 中 DRA 的三项关键增强默认启用：

此前，GPU 调度采用整数分配模型——无论实际利用率如何，一整张 GPU 被分配给单个 Pod。DRA 的成熟让细粒度的加速器资源共享成为可能，这对于提高 GPU 集群利用率至关重要。

“以前请求复杂资源通常需要不透明的、供应商特定的配置，调度器难以优化。” —— VMware Cloud Foundation 团队

2.2 Workload-Aware Preemption（Alpha）

分布式训练任务的一个经典痛点：调度器抢占单个 Pod，导致 8 卡训练任务中 7 个 rank 仍在运行，但无法继续推进。

v1.36 引入的 Workload-Aware Preemption 将 PodGroup 视为单一抢占单元，只有在确认高优先级组确实能完整调度后，才会执行驱逐。

apiVersion: scheduling.x-k8s.io/v1alpha1
kind: PodGroup
metadata:
  name: training-job-8gpu
spec:
  schedulePolicy:
    preemptionPolicy: PreemptLowerPriority
  minMember: 8  # 必须同时调度 8 个 Pod

2.3 Gang Scheduling API 晋升 Beta

Gang Scheduling 确保一组关联 Pod 要么全部调度成功，要么全部不调度。v1.35 的 Alpha 特性在 v1.36 中进入 Beta，与 Workload-Aware Preemption 配合，构成了 AI 工作负载调度的基础设施。

2.4 挂起作业的可变资源（Beta）

队列控制器现在可以：

1. 挂起正在运行的作业
2. 调整 CPU/内存/GPU 资源请求
3. 恢复作业而无需销毁/重建 Pod

apiVersion: batch/v1
kind: Job
metadata:
  name: adaptive-training
spec:
  suspend: true  # 挂起
  template:
    spec:
      containers:
      - name: trainer
        resources:
          requests:
            nvidia.com/gpu: 4  # 从 8 卡调整为 4 卡

这消除了自定义控制器或完全重启作业的需求，对于动态资源配额调整场景（如夜间批处理让位于在线服务）非常实用。

三、大规模集群的 API 可扩展性

3.1 Sharded List and Watch Streams（Alpha）

超大规模集群中，单一资源类型的 watch 流可能成为瓶颈。v1.36 引入的分片机制将 watch 负载分布到多个流上，解决了”单连接单资源类型”的架构限制。

“这是解决超大规模部署中 watch 流瓶颈的关键痛点。” —— Palark 团队

3.2 内存 QoS 与原地垂直扩缩容

cgroup v2 的分层内存保护机制与 Pod 的 request/limit 对齐，提供了更可预测的内存性能隔离。

原地垂直扩缩容（In-Place VPA）在 v1.36 中进入 Beta 并默认启用，允许调整 Pod 级别的 CPU/内存上限而无需重启容器。新增的 ResizeDeferred 事件类型确保在容量不足时 Pod 继续以现有规格运行，kubelet 在资源可用时自动重试。

四、移除与弃用：清理技术债

gitRepo 的移除尤其值得关注——它”允许攻击者以 root 身份在节点上运行代码”，是一个长期存在的安全隐患。

五、关键运维提醒：Ingress NGINX 已退役

2026 年 3 月 24 日，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 控制器退役。自该日期起：

• 不再发布新版本
• 不再提供 bug 修复
• 不再提供安全补丁

使用 Ingress NGINX 的集群需要尽快迁移到替代方案（如 Traefik、Istio Gateway、或 Cilium Gateway API）。

六、总结：Kubernetes 的”成人礼”

v1.36 的发布反映了 Kubernetes 社区的成熟判断：安全不再是可选配置，AI 工作负载不再是边缘场景，大规模运维不再是少数巨头的专利。

对于平台工程师，这意味着：

1. 升级计划需要纳入安全默认变更的影响评估
2. AI 工作负载的调度策略需要重新设计
3. Ingress NGINX 的迁移不能再拖

对于应用开发者，User Namespaces 和 Mutating Admission Policies 的 GA 意味着可以在不牺牲安全性的前提下获得更大的部署灵活性。

Kubernetes 正在从一个”你可以做任何事”的灵活框架，演变为一个”默认就做对的事”的生产级平台。这个转变，正是云原生技术走向成熟的标志。

参考链接：

• Kubernetes v1.36 Release Notes
• InfoQ: Kubernetes v1.36 Released
• Ingress NGINX Retirement Announcement

我的工作台是这样的：家里一台 Mac mini，公司一台 MacBook Pro，还有一台云服务器跑一些常驻服务。三台设备上都装着一堆 AI Agent——Claude Code、Codex、OpenClaw、Pi、Kimi、OpenCode，有些用得频繁，有些偶尔需要。

最近时间我在引入 Multica（一个让 Agent 像真实团队成员一样协作的开源平台）。它确实做到了任务分配、进度追踪、技能复用，能把 Claude Code、Codex、OpenClaw 这些 Agent 当成同事来管理——你在 Multica 的看板上建一个 Issue，分配给 Claude Code，它会自主认领、执行、汇报，跟你在 Slack 里协作没什么两样。

Multica 让多个 Agent 协作做一件事变得高效，但它也放大了另一个问题：每个 Agent 的记忆几乎独立——我在 Claude Code 里积累的上下文，OpenClaw 不知道；我在 Mac mini 上调好的偏好，MacBook 上要从头再来。

我的架构偏好、当前项目背景、调试到一半的思路——这些东西，每换一个 Agent、每换一台设备，就归零一次。

二、第一次尝试：Mempalace

调研了一圈，发现 Mempalace 这个项目专门做 Agent 记忆管理。装上之后确实好用——它能把我的偏好、项目背景、历史对话整理成结构化记忆，下次打开 Agent 可以直接召回。

但很快撞上了天花板：单机。

Mempalace 的记忆文件存在本地，Mac mini 上积累的记忆，MacBook 一点都看不到。我研究过把它的 MCP 接口从本地 stdio 转成 HTTP stream 的方案，这样可以把 mempalace 集中在一台服务器上维护，实现远程访问。但不优雅的是需要额外引入一个转换组件来做协议适配——多了一层中间层，不够干净利落。

我需要的是一个原生就跑在云端的记忆中枢。

三、意外发现：OpenHuman 背后的 AgentMemory

有天在 GitHub 刷项目，看到一个叫 OpenHuman 的东西——”你的个人 AI 超级智能”。点进去，发现它的底层记忆后端用的是 AgentMemory。

顺手把 AgentMemory 的 README 从头读到尾。读完眼睛亮了。

这个项目目前在 GitHub 上有 11.6k star，被称为”基于真实 benchmark 排名第一的 AI 编码 Agent 持久记忆系统”。它的核心能力正好命中我的所有需求：

它做到了我一直想要的几件事

支持远程 MCP（HTTP 协议），Agent 在哪台设备都能接入
支持 API Key 认证，只有我的 Agent 才能读我的记忆
三路混合检索：BM25 关键词 + 向量语义 + 知识图谱，再用 RRF 融合排序
四层记忆整合：工作记忆 → 情节记忆 → 语义记忆 → 程序记忆，像人脑一样分层巩固
兼容几乎所有主流 Agent：Claude Code、Codex、OpenClaw、Pi、Kimi、OpenCode 全支持
不依赖外部数据库，SQLite + iii-engine，自包含部署

更关键的：它原生支持云端部署，提供了 Fly.io、Railway 的一键模板，专门为多设备、多 Agent 的场景设计。这才是我要找的东西。

四、云端部署

选定方案之后，用 OpenClaw 直接部署 AgentMemory 到云服务器。

部署完成后配置 API Key，在各设备的 Agent 里加上 MCP 连接，验证返回 {"status": "healthy"} 即上线成功。

所有设备的所有 Agent，从此共享同一层记忆。

五、现在是什么感觉

接入之后最直接的变化：我在 Mac mini 上用 Claude Code 做了一段工作，讨论了架构决策、确定了代码风格偏好、记录了一个待解决的问题。切换到 MacBook 打开 OpenClaw，它能通过语义检索找到刚才积累的上下文——不需要我重新解释，直接接着上次的思路走。

AgentMemory 能做到语义检索，搜索”agentmemory 远程状态”这类自然语言，能准确召回相关记录，相似度指标显示匹配质量很高——这是纯关键词匹配做不到的。

目前的架构是这样的：

下一步要做的：

• 把偏好文件（USER.md、SOUL.md 里的关键设定）系统性地写入记忆
• 把 Mempalace 单机时代积累的历史数据迁移过来
• 逐步接入剩余的几个 Agent，验证跨 Agent 记忆共享的完整性

六、这件事给我的启发

1. Agent 协作和 Agent 记忆是两个层次的问题 — Multica 解决的是前者，AgentMemory 解决的是后者。两个工具不冲突，分别在不同维度给 Agent 团队赋能。

2. 个人记忆必须上云 — 本地记忆方案注定是单机的，而我的工作流天然跨设备。”记忆在云上”和”代码在 GitHub 上”一样自然，不该将就。

3. 认证是底线 — 远端记忆服务暴露在公网，API Key 是最低要求。裸奔的记忆系统等于裸奔的云服务器。

4. 语义检索远胜关键词 — 搜”数据库性能问题”能召回”修了一个 N+1 查询”——这不是关键词匹配能做到的。BM25 + 向量 + 图谱融合检索是真实可用的，不只是 README 里的宣传词。

5. 渐进接入，不要一次全上 — 先跑通一个 Agent，确认写入和检索链路完整，再逐步扩展。一次全上出问题找不到根因。

七、我真正想要的

部署 AgentMemory 只是基础设施层面的一步。

我真正想要的是：无论打开哪台设备、无论启动哪个 Agent，它都已经知道我是谁——

我是做平台架构的，习惯先看全局再动手
我喜欢直接型沟通，不需要废话和铺垫
我偏向 Python / Golang、Kubernetes、AI Agent 这个技术方向
我上周讨论过的架构决策，这周要继续往下推
我有一些长期悬而未决的技术问题，不用每次重新解释背景

这些东西，应该像 Git 仓库一样，在任何设备上 pull 一下就有了。

AgentMemory 是实现这个愿景的基础设施。接下来要做的，就是把”我”系统性地写入云端，让每个 Agent 都能读到。

如果你也在用多个 AI Agent，也被跨设备的记忆分裂折磨过，希望这篇文章对你有用。

原文首发于微信公众号「翊行代码」

前者找得到字面匹配，但理解不了语义；后者准一点，但 token 消耗随代码量线性膨胀。一个中等规模的微服务仓库，几轮搜索下来就能烧掉几十万 token。

Semble 想解决的是同一个问题的第三个维度：既要语义准确，又要 token 极简，还要本地毫秒级响应。

为什么 grep + read 不是答案

Claude Code、Cursor 这类 Agent 的默认代码搜索链路大致是这样的：

1. 用 grep 或 ripgrep 按关键词扫一遍文件列表
2. 把匹配到的文件整块读进上下文
3. LLM 从中筛选出真正相关的片段

这个流程的问题不在 grep，而在「读整文件」。一个 500 行的模块文件，真正相关的可能只有 10 行，但剩下的 490 行照样占用 token 预算。按 Claude 的计费方式，这 490 行就是纯浪费。

更隐蔽的成本在交互轮次。Agent 第一次搜索没找到，会换关键词再搜；找到一部分后，又会顺着引用链继续读更多文件。几轮下来，token 消耗轻松破万。

Semble 的 benchmark 数据很直观：同样的检索任务，grep+read 平均消耗约 50 倍于 Semble 返回的 snippet 字符数。换算成 token，就是 98% 的节省空间。

核心设计：静态嵌入 + BM25 双路召回

Semble 的检索架构并不复杂，但每个组件的选择都指向同一个目标——零外部依赖的极速本地搜索。

flowchart LR
    A["Codebase"] --> B["Chonkie<br/>代码感知分块"]
    B --> C["potion-code-16M<br/>静态嵌入模型"]
    B --> D["BM25<br/>词项索引"]
    C --> E["语义得分"]
    D --> F["词项得分"]
    E --> G["RRF 融合"]
    F --> G
    G --> H["代码感知重排序"]
    H --> I["Top-K 结果"]

第一层：代码感知分块

用 Chonkie 做初始切分，不是简单的按行数或字符数切，而是尊重代码的结构边界——函数、类、逻辑块。这样保证返回的 snippet 在语义上是完整的，Agent 拿到就能用，不需要再拼接上下文。

第二层：双路召回

• 语义路：potion-code-16M，一个 1600 万参数的静态嵌入模型。静态的意思是查询时不需要 transformer 前向传播，直接查表取 embedding，所以能在 CPU 上跑到毫秒级。
• 词项路：BM25，负责精确匹配标识符、API 名、类名。你搜 save_pretrained，BM25 能确保包含这个函数定义的文件排在前面。

两路结果用 RRF（Reciprocal Rank Fusion）融合，兼顾「意思相近」和「字面命中」。

第三层：代码感知重排序

融合后还有一组针对代码场景的微调信号：

• 定义提升：包含 class Foo 或 def bar 的块，比单纯引用 Foo 的块排名更高
• 标识符词干：搜 parse config 时，parseConfig、ConfigParser、config_parser 都会被加权
• 文件连贯性：同一文件多个块命中时，整文件权重提升
• 噪声惩罚：测试文件、compat shim、.d.ts stub 会被降权

整个流程在普通笔记本 CPU 上的耗时：索引一个平均规模的仓库约 250ms，单次查询约 1.5ms。

与 Transformer 方案的对比

Semble 的 NDCG@10 是 0.854，对比专门的代码 Transformer 模型（如 CodeRankEmbed），保留了约 99% 的检索质量。但速度和成本完全不在一个量级：

这个 trade-off 的合理性取决于使用场景。如果你在做离线代码分析，50 秒索引一次完全可以接受；但如果 Agent 每轮对话都可能触发一次代码搜索，250ms vs 50 秒就是可用和不可用的区别。

MCP 集成：一行命令接入 Agent

Semble 提供了原生的 MCP server，对接成本极低。

Claude Code 用户直接执行：

claude mcp add semble -s user -- uvx --from "semble[mcp]" semble

Cursor 用户在 ~/.cursor/mcp.json 里加一段配置：

{
  "mcpServers": {
    "semble": {
      "command": "uvx",
      "args": ["--from", "semble[mcp]", "semble"]
    }
  }
}

Codex、OpenCode 同理，都是一行配置的事。

MCP 暴露两个工具：

• search：用自然语言或代码片段搜索仓库，支持本地路径或 git URL
• find_related：给定文件路径和行号，返回语义相似的代码块

远程仓库会被自动克隆并缓存索引，本地路径则会被监控文件变更、实时重建索引。

实战：在真实项目里省了多少 token

Semble 内置了 token 节省统计，执行 semble savings 可以看到累计数据：

Period        Calls   Savings
────────────────────────────────────────
Today         42      ~58.4k tokens (95%)
Last 7 days   287     ~312.4k tokens (90%)
All time      1.4k    ~1.2M tokens (89%)

计算方式很直接：(file_chars - snippet_chars) / 4，按平均每 token 4 字符估算。假设一个 Agent 每天执行 40 次代码搜索，一年下来能省掉约 2000 万 token。按当前主流模型的 API 价格，这是数千美元量级的成本差异。

但比钱更重要的是上下文窗口的释放。Agent 的上下文是有限的，省下来的 token 可以用来放更多相关代码、更长的对话历史，或者更复杂的推理链。

局限与适用边界

Semble 不是万能药，有几个场景它并不擅长：

跨仓库语义关联。它擅长在一个代码库内找相关实现，但如果你想问「这个项目和那个项目的设计模式有什么异同」，Semble 帮不上忙。

动态代码生成。对于模板元编程、宏展开后的代码，静态分块可能切不到最有意义的边界。

超大规模单体仓库。虽然索引速度是线性的，但千万行级别的仓库在消费级硬件上的首次索引时间可能达到秒级，不再是「无感知」的体验。

另外，potion-code-16M 是英语和主流编程语言优化的模型，对于以中文注释为主、或小众语言（如 Coq、Lean）占主导的仓库，语义路的效果会有折扣。

总结与行动

Semble 的价值不在于发明了新的检索算法，而在于把正确的组件组合成了一个 Agent 原生的工作流。

• 静态嵌入砍掉了 GPU 依赖和 API 成本
• BM25 保证了标识符级别的精确召回
• 代码感知的重排序让结果更符合开发者的直觉
• MCP 封装让集成成本降到一行命令

如果你正在用 Claude Code 或 Cursor 处理大型代码库，可以按这个 checklist 验证效果：

1. 安装 Semble MCP：claude mcp add semble -s user -- uvx --from "semble[mcp]" semble
2. 在项目中执行一次语义搜索，对比默认 grep 的返回质量
3. 观察 Agent 后续对话的 token 消耗变化
4. 用 semble savings 跟踪一周累计数据
5. 对于高频搜索的仓库，把索引预热加到项目启动脚本里

Agent 时代的基础设施正在快速分层。Semble 属于「让 Agent 看得更少、看得更准」的那一层，而这类工具的普及，会直接决定大规模代码重构、遗留系统维护等复杂任务能否真正交给 AI 自动完成。

这条路径的核心差异不是「谁能点按钮」，而是数据主权归谁。

为什么云端方案不够

现有的 AI 浏览器自动化工具大致分两类：

一类是云端托管浏览器，比如 OpenAI Operator、Perplexity Comet。Agent 在服务商的服务器上运行一个无头浏览器，你通过自然语言发指令。问题是：你的登录态、Cookie、页面内容全部流经第三方基础设施。

另一类是桌面级自动化，比如 Anthropic Computer Use。它在你的机器上运行，但通常需要独立的虚拟桌面或容器环境，与日常使用的浏览器隔离。

对于企业场景，这两类方案都有硬伤：

• 敏感数据外泄：内部系统、银行页面、邮件内容不可能送到云端
• 登录态隔离：云端浏览器没有你的企业 SSO 登录态，遇到需要身份验证的页面直接卡住
• 上下文断裂：自动化浏览器和日常浏览器是两回事，用户需要来回切换

Kimi WebBridge 的解法很直接：不新建浏览器，直接接管你已经在用的那个。

架构拆解：本地优先意味着什么

WebBridge 由两部分组成：

flowchart LR
    A[Chrome Extension] <-->|Chrome DevTools Protocol| B[Local Background Service]
    B <-->|WebSocket / stdio| C[AI Agent<br/>Claude Code / Cursor / Codex]

浏览器扩展安装在现有 Chrome/Edge 中，拥有当前页面的完整访问权限——包括 Cookie、LocalStorage、登录态。

本地后台服务是一个独立进程，通过 Chrome DevTools Protocol（CDP）与扩展通信。CDP 是开发者调试浏览器时用的同一套底层接口，可以执行点击、输入、截图、DOM 查询等操作。

Agent 连接支持多种方式：Kimi Code CLI 原生集成；Claude Code、Cursor、Codex 通过一条连接命令接入。

关键设计：Moonshot 的服务器不参与任何页面内容传输。扩展和后台服务之间的通信完全在本地完成。

与 MCP 生态的关系

今年 Google 官方推出了 Chrome DevTools MCP Server，让 AI 编码助手能通过 MCP 协议调试网页。WebBridge 和它的关系值得理清：

两者不是竞争关系，而是互补。开发阶段用 Chrome DevTools MCP 调试页面；生产自动化用 WebBridge 操作真实业务环境。

一个更实际的观察是：MCP 作为协议层正在标准化工具调用的接口，但具体「工具做什么」仍然由各实现决定。WebBridge 可以被视为一种特殊的「浏览器工具」，未来完全可能通过 MCP 暴露给更多 Agent。

能做什么，不能做什么

从现有信息看，WebBridge 支持的操作包括：

• 打开页面、点击元素、填写表单
• 滚动、截图、提取文本
• 跨站点内容整合
• 在已登录状态下操作（如后台管理、SaaS 平台）

典型场景举例：

“从 LinkedIn 搜索 5 个符合条件的候选人，把姓名和职位整理成表格”

Agent 会打开 LinkedIn（已登录）、执行搜索、逐一点开个人页、提取信息、汇总输出。全程不需要你手动操作。

但限制也很明显：

• 依赖页面稳定性：DOM 结构一变，选择器可能失效
• 无法处理复杂验证码：图形验证码、reCAPTCHA 等仍需人工介入
• 长流程可靠性未知：涉及 10+ 步骤的跨站操作，中间任一环节失败都会中断

工程视角的评估

安全模型

本地优先架构的安全优势是真实的：页面内容、Cookie、截图都不离开本机。但需要注意两个细节：

1. Agent 本身仍然可能泄露数据。如果连接的是云端模型（如 Claude API），页面提取的文本会被发送到模型服务商
2. 后台服务的权限边界。CDP 的权限很高，能做的事不止「点击按钮」。需要确认本地服务是否有沙箱隔离

与 RPA 的区别

传统的 RPA（Robotic Process Automation）工具也能做浏览器自动化，但通常基于录制回放或固定脚本。WebBridge 的差异在于：

• 自然语言驱动：用 prompt 描述目标，而非预定义步骤
• 视觉理解：结合截图让模型判断页面状态
• 容错能力：遇到意外弹窗或布局变化，模型可以尝试重新定位元素

性能考量

CDP 操作本身很快，但瓶颈在模型推理。每步操作（截图 → 发送模型 → 解析响应 → 执行点击）的延迟取决于模型服务商的响应时间。本地模型（如 Kimi K2.6）可以消除网络延迟，但硬件要求更高。

对国内团队的启示

WebBridge 的发布释放了一个明确信号：浏览器自动化正在从「云端托管」向「本地原生」分化。

对于需要操作内部系统的企业，本地方案几乎是唯一选择。几点直接可用的参考：

第一，评估现有 RPA 工具的替代可能。 如果团队已经在用 Selenium、Playwright 写固定脚本，可以尝试用 Agent 驱动同一套底层能力，把「写脚本」变成「写 prompt」。

第二，关注 MCP 协议的浏览器工具链。 Chrome DevTools MCP、Playwright MCP 等正在形成标准接口，未来 Agent 切换浏览器后端的成本会降低。

第三，安全策略需要重新设计。 本地 Agent 操作浏览器意味着「人 + AI」共用同一套身份。传统的「按人授权」模型需要扩展为「按会话授权」，区分人工操作和 Agent 操作的行为边界。

总结与行动

Kimi WebBridge 的价值不在于技术突破，而在于它选择了一个被忽视的方向：在数据主权和自动化能力之间，优先保证前者。

三个关键判断：

1. 本地优先是刚需，不是偏好。 涉及登录态和敏感数据的场景，云端方案天然不适用
2. CDP 是事实标准。 Chrome DevTools Protocol 已经成为浏览器自动化的通用底层，围绕它的工具生态会继续扩大
3. Agent + 浏览器的组合还在早期。 可靠性和容错能力距离生产级要求有差距，适合辅助场景而非关键流程

如果你正在探索 AI Agent 的落地场景，可以从一个低风险任务开始：让 Agent 帮你整理周报数据、汇总竞品信息、或批量处理后台表单。用 WebBridge 或 Playwright MCP 都可以，重点不是工具，而是验证「自然语言驱动浏览器」在你的业务场景里是否可靠。

参考来源：

• Kimi WebBridge 官方页面
• Chrome Web Store - Kimi WebBridge
• Chrome DevTools MCP - Google Developers
• 5 Best MCP Servers for Browser Automation - Webfuse

过去十年，”云原生”架构建立在一个 20 年前的假设上：状态存储在数据库，计算是无状态的。LLM 和 Agent 的出现，正在从三个维度瓦解这个假设。

一个正在失效的架构契约

2006 年左右，Web 架构达成了一项隐性契约：

• 数据库 = 状态
• 应用服务器 = 无状态
• 负载均衡器 = 不关心请求发给谁

这套设计让水平扩展变得简单——数据库垂直扩容（换更大的机器），应用服务器水平扩容（增加更多机器）。任何请求都可以发给任何服务器，负载均衡器只需要做轮询。

这个假设支撑了从单体到微服务的整个演进路径，也定义了我们熟悉的 “stateless HTTP + load balancer + database” 三元组。

但 LLM 和 Agent 正在让这套契约失效。

三个被违反的假设

假设一：请求应该在毫秒级完成

传统 API 设计假设一次请求在几百毫秒内返回。但一个 Agent 任务可能运行 10 分钟——调用工具、等待结果、继续推理、再调用下一个工具。

这不是 “慢请求”，这是 异步进程。

假设二：计算应该是无状态的

无状态意味着服务器不保留任何请求间的上下文。但多轮对话、工具调用链、累积的上下文窗口——这些都是 Agent 的记忆，不是数据库状态。

把 Agent 的每一步推理结果都写回数据库，再用轮询拉回来，本质上是在用数据库当消息总线。

假设三：用户只需要结果，不需要过程

传统架构假设客户端发起请求、拿到响应、结束。但用户想 观看 Agent 的思考过程、中断 错误的推理方向、重定向 任务目标。

这是一种与进程的 双向对话，不是一次性的状态less查询。

为什么 Durable Execution 不够

Temporal、Inngest、Restate 等 Durable Execution 框架解决了 执行韧性 问题——让长进程在崩溃后能够恢复。但它们没有解决 交互 问题。

┌─────────────┐     HTTP      ┌─────────────┐
│   Client    │ ────────────▶ │   Server    │
└─────────────┘               └─────────────┘
                                    │
                                    ▼
                              ┌─────────────┐
                              │  Temporal   │
                              │  Workflow   │
                              └─────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
              ┌─────────┐    ┌─────────┐    ┌─────────┐
              │  Poll   │    │  Poll   │    │  Poll   │
              └─────────┘    └─────────┘    └─────────┘

上图是当前的主流方案：Durable Execution 负责 resilient 执行，但客户端仍然通过轮询数据库获取进度。

轮询是一个路由问题的 workaround。

HTTP + 负载均衡器 + 无状态服务器 无法路由到特定进程。它只能路由到数据库。所以业界发明了轮询这个通用 workaround——但 latency、数据库负载、浪费的请求、糟糕的流式体验，这些问题一个都没解决。

“Polling is what you do when you can’t figure out how to address the thing you want to talk to.”

缺失的原语：可路由的传输名称

我们需要的是一个 可路由的传输名称，它不是服务器，不是连接，而是一个 地址。

目标是：”把这条消息交付给正在为 workflow X 产生输出的那个进程”——而无需知道它在哪台机器、哪个副本、哪个进程 ID。

WebSocket 为什么不行

WebSocket 是 连接，不是地址。它通过直接的客户端-服务器链路一次性解决了路由问题，但连接断开后，”地址” 就丢失了。你无法重新连接到同一个进程。

Pub/Sub Channel 的反转

Pub/Sub Channel 反转了所有权：

• 服务器进程不可寻址
• 客户端不可寻址
• 传输通道本身可寻址

双方都通过 名称 连接到同一个 channel，实现双向、有状态的通信。连接断开/重连不会丢失数据或破坏路由。

┌─────────────┐         ┌─────────────┐
│   Client    │◄───────►│   Channel   │◄───────►│  Workflow   │
│  (any box)  │  "wf-123"│  (by name)  │  "wf-123"│  (any box)  │
└─────────────┘         └─────────────┘         └─────────────┘
       │                                               │
       └──────────── 双向通信，双方都可断开/重连 ─────────────┘

Temporal 的示例：workflow activity 连接到以 workflow ID 命名的 pub/sub channel，客户端也连接到同一个 channel 获取更新 + 发送中断/转向指令。无论 workflow 进程还是客户端连接如何中断，重连到同一个 channel 就能恢复通信。

这消除了：

• 通过数据库传递数据
• 轮询
• 无法寻址的 durable 进程

为什么 LLM 让这个问题显性化

这个问题不是 LLM 带来的，但 LLM 让它的代价变得不可接受：

以前连接断开，请求足够便宜可以重试，而且响应是确定性的。现在一个 10 分钟的 Agent 任务中断后重试，可能产生完全不同的结果，而且你已经为中断前的 token 付过费了。

你也不想为了让客户端连接更 resilient，就把每个 token 都写进数据库。

推荐的架构分层

┌─────────────────────────────────────────────┐
│           Stateless HTTP Layer              │
│    (传统请求/响应，短连接，无状态)            │
├─────────────────────────────────────────────┤
│         Durable Execution Layer             │
│    (Temporal/Restate，长进程，执行韧性)       │
├─────────────────────────────────────────────┤
│         Pub/Sub Channel Layer               │
│    (可寻址、可重连、双向传输)                 │
└─────────────────────────────────────────────┘

无状态 Web 没有错，它只是不适合 Agentic 应用——这些应用需要长运行、有状态、可交互的进程。我们需要一种新的架构，包含能够寻址 进程 而不仅仅是数据库的路由原语。

实战：一个最小可用的 Agent 通道设计

假设你正在构建一个内部 AI 平台，支持多步 Agent 工作流。以下是一个最小可用的 channel 设计：

import asyncio
from dataclasses import dataclass
from typing import AsyncIterator, Callable

@dataclass
class AgentChannel:
    """可寻址的 Agent 通信通道"""
    workflow_id: str
    _inbox: asyncio.Queue
    _outbox: asyncio.Queue
    
    async def send(self, msg: dict) -> None:
        """向 workflow 发送指令/中断"""
        await self._inbox.put(msg)
    
    async def receive(self) -> AsyncIterator[dict]:
        """接收 workflow 的流式输出"""
        while True:
            msg = await self._outbox.get()
            if msg.get("type") == "done":
                break
            yield msg

class ChannelRegistry:
    """按 workflow_id 寻址的通道注册表"""
    _channels: dict[str, AgentChannel] = {}
    
    @classmethod
    def get_or_create(cls, workflow_id: str) -> AgentChannel:
        if workflow_id not in cls._channels:
            cls._channels[workflow_id] = AgentChannel(
                workflow_id=workflow_id,
                _inbox=asyncio.Queue(),
                _outbox=asyncio.Queue(),
            )
        return cls._channels[workflow_id]
    
    @classmethod
    def remove(cls, workflow_id: str) -> None:
        cls._channels.pop(workflow_id, None)

这个设计的核心思想：

• Channel 是地址，不是连接
• Workflow ID 是路由键，不是进程 ID
• 双方都可以断开/重连，不影响通信连续性

踩坑与对比

常见错误一：用数据库当消息总线

把 Agent 的每一步输出都写入数据库，客户端轮询读取。这在小规模可行，但：

• 数据库成为瓶颈
• 轮询间隔 = latency 与负载的权衡
• 流式体验差

常见错误二：WebSocket 直接连接 Agent 进程

WebSocket 连接绑定到特定进程，进程崩溃后客户端无法重连到同一逻辑工作流。

备选方案对比

总结与行动

1. 识别你的 Agent 工作流：哪些任务超过 10 秒？哪些需要用户交互？
2. 评估当前架构：是否在用数据库轮询或 WebSocket 直接连接？
3. 引入 Channel 抽象：即使先用 Redis Pub/Sub 或 SSE + 重连逻辑，也比轮询更接近正确方向
4. 分离关注点：Stateless HTTP 处理短请求，Durable Execution 处理长进程，Channel 处理双向交互
5. 从小处开始：不需要一次性替换整个架构，先在一个 Agent 工作流中验证 Channel 模式

参考

• LLMs are breaking 20 year old system design — /dev/knill
• Accelerating LLM-Driven Developer Productivity at Zoox — InfoQ QCon SF 2026

当大多数团队还在争论「用 LangChain 还是 LlamaIndex」时，Zoox 的工程师选择了一条更激进的路：不用任何框架，从零搭建一个支撑 100+ 内部客户端、多模型、多模态、Agent 工作流的 AI Gateway。这个决策背后的思考，比框架选型本身更值得参考。

痛点：为什么现成的方案不够用

Zoox 是一家自动驾驶公司，工程师需要处理的问题高度复杂：代码库庞大、文档散落在 Confluence/GitHub/Slack、涉及文本/图像/视频多种数据类型，且对安全和合规有严格要求。

2025 年之前，团队尝试过直接使用 ChatGPT 等公开工具，很快发现三个致命问题：

第一，数据出不去。 核心代码、车辆数据、乘客信息不可能送到第三方云端。

第二，集成深度不够。 公开工具无法访问 Zoox 内部的 Jira、Confluence、Slack、部署系统，回答永远停留在「通用建议」层面。

第三，团队各自为战。 不同组用不同工具，有人用 Claude，有人用 GPT，有人自己搭 RAG——能力重复建设，经验无法复用。

这三个问题指向同一个结论：企业需要的不是「更好的模型」，而是「可控的 AI 基础设施」。

Cortex 的架构演进

Zoox 的解法是从一个薄层开始，逐步演化成完整平台：

flowchart LR
    A[Phase 1: AWS Bedrock Gateway] --> B[Phase 2: Multi-Modality APIs]
    B --> C[Phase 3: LiteLLM Multi-Provider]
    C --> D[Phase 4: RAG Pipelines]
    D --> E[Phase 5: Agent Loop]
    E --> F[Phase 6: Agents-as-API]

第一阶段：统一模型访问。 通过 AWS Bedrock 接入 Claude、Nova 等模型，解决「多模型切换」问题。

第二阶段：多模态支持。 增加图像、视频、音频的推理 API，满足自动驾驶场景对视觉数据的分析需求。

第三阶段：多供应商抽象。 引入 LiteLLM 统一不同云厂商的 API 差异，随后接入 GCP + Gemini，补足视觉任务能力。

第四阶段：RAG 知识库。 关键洞察来自生产实践：「为每个数据源单独建知识库，比把所有文档塞进一个向量库效果好得多」。Confluence、Slack、GitHub README 分别建库，检索准确率显著提升。

第五阶段：Agent 能力。 LLM + Tools 的循环推理，让系统能自主决定调用哪些内部工具。

第六阶段：Agents-as-API。 这是 Cortex 最具差异化的设计。

Agents-as-API：把 Agent 变成基础设施

传统 Agent 框架（Google ADK、LangChain 等）的部署模式是：每个团队自己搭一套 Agent 运行时，维护工具注册、执行环境、安全策略。

Cortex 反过来了：

flowchart TB
    subgraph "传统模式"
        T1[团队A Agent] --> T1Tools[自建工具栈]
        T2[团队B Agent] --> T2Tools[自建工具栈]
    end
    subgraph "Cortex 模式"
        C1[团队A 调用 API] --> Gateway[Cortex Gateway]
        C2[团队B 调用 API] --> Gateway
        Gateway --> Registry[中央工具注册表]
        Gateway --> Execution[统一执行/安全/观测]
    end

团队只需要做两件事：

1. 在中央注册表里定义自己的工具
2. 调用 REST API，传入 {model, prompt, tool_list}

Cortex 负责启动轻量级 Agent、执行工具调用、处理限流、配额、审计、人工确认。团队只关心业务逻辑，平台负责执行、扩缩容和安全。

一个具体例子：Zoox Intelligence Slack Bot 在同一个代码部署下，为不同频道激活不同工具集——基础设施频道用「事件管理 + 部署工具」，招聘频道用「日历 + 邮件工具」。配置一变，行为就变，无需改代码。

关键工程决策

不用框架，自己写

Cortex 刻意避开了 LangChain、LlamaIndex 等框架。原因很务实：

• 框架更新太快，生产环境经不起频繁 breaking change
• 抽象层太厚，出问题后调试困难
• 需求太特殊，自动驾驶场景的很多需求（多模态、实时性、车规合规）框架本身不支持

这不是说框架不好，而是说：当你的规模足够大、场景足够特殊时，框架的「通用性」反而成为负担。

工作流优先于 Agent

Zoox 内部把 AI 应用分为两类：

推荐策略：先从 Workflow 开始，只有真正需要自主性时才引入 Agent。

Workflow 可预测、可测试、好调试。Agent 灵活但难排查。Zoox 的实践经验是，80% 的场景用 Workflow 就够了。

人工确认不是可选项

Cortex 对所有「写操作」工具强制加 @require_confirmation 装饰器。Agent 调用时，先展示详情给用户，等待确认后才执行。

一个真实教训：某 Agent 未经确认就在公共频道向法务团队发消息索要权限。如果没有这道关卡，类似操作的后果可能更严重。

@require_confirmation
def create_jira_ticket(title: str, description: str) -> dict:
    """创建 JIRA 工单，需要人工确认"""
    # 业务逻辑...

生产踩坑记录

大媒体输入的 DDoS 风险

高分辨率图像直接送入模型会打爆平台。必须在前置层做验证和预处理，按场景决定分辨率上限。

夜间鱼眼图像的识别难题

自动驾驶场景的夜间鱼眼图像，连人类都难以辨认，不能对模型期望过高。需要结合传统 CV 做预处理。

实时 vs 批量的资源隔离

百万级标注图像属于批量任务，应该走 Bedrock/GCP 的批处理通道，而不是占用 Cortex 的实时推理资源。

MCP 的「过度设计」陷阱

Zoox 对 MCP 持谨慎态度，认为它「试图做太多事情」。在内部工具已经足够标准化的情况下，引入 MCP 的复杂度大于收益。

与行业方案的对比

对国内团队的启示

Cortex 的实践对正在建设 AI 平台的技术负责人有几个直接可用的参考：

第一，RAG 不要做大杂烩。 按数据源拆知识库，检索准确率比「一个超大向量库」高得多。

第二，Agent 不是银弹。 先把确定性流程用 Workflow 跑起来，再考虑哪里需要 Agent 的自主性。

第三，安全策略必须内建在平台层。 不能指望每个业务团队自己实现人工确认、限流、审计——这些应该由平台统一提供。

第四，框架选型要务实。 不是「不用框架就高级」，而是「框架的抽象是否匹配你的场景」。团队规模小、需求标准，用框架更快；规模大、需求特殊，自研更可控。

总结与行动

Zoox Cortex 的核心价值不在于技术有多新，而在于它回答了一个务实的问题：企业级 AI 平台到底该长什么样？

它的答案可以概括为三点：

1. 模型是插件，不是核心。 今天用 Claude，明天切 GPT，平台层不应该感知差异。
2. Agent 是 API，不是应用。 业务团队不应该维护 Agent 运行时，只应该调用 Agent 能力。
3. 安全是默认，不是配置。 人工确认、限流、审计、配额——这些必须是平台级强制策略，不是可选项。

如果你正在规划或建设内部的 AI 平台，不妨用这三个标准审视现有方案：模型切换成本有多高？业务团队维护 Agent 的负担有多重？安全策略是统一强制还是各自实现？

Cortex 用一年多的生产实践证明了：无框架不是目的，可控才是。

参考来源： Accelerating LLM-Driven Developer Productivity at Zoox - Amit Navindgi, InfoQ 2026

当 AI 编码工具从「玩具」变成「生产基础设施」，企业面临的核心问题不再是「用哪个模型」，而是「如何在保证安全与可控的前提下，让 AI 真正融入开发工作流」。Coder Agents 给出的答案值得关注。

背景：AI 编码代理的「最后一公里」难题

2025 年到 2026 年，AI 编码工具经历了从「尝鲜」到「常态化」的跨越。GitHub Copilot、Cursor、Claude Code、Codex CLI……这些工具让开发者的效率获得了数量级的提升。但企业在规模化落地时，很快撞上了一堵墙：

云服务的便利性与企业治理需求之间的冲突。

代码是企业的核心资产。让 AI 模型在第三方云端处理内部代码，涉及数据隐私、合规审计、安全边界等一系列敏感问题。更棘手的是，不同团队可能使用不同的 AI 工具，导致执行环境碎片化、管理策略难以统一。

Coder（一家专注于云开发环境的公司）看到了这个痛点，并于 2026 年 5 月推出了 Coder Agents——一个模型无关的 AI 编码代理编排平台。

Coder Agents 是什么

Coder Agents 的核心理念可以用一句话概括：把「智能」和「基础设施」解耦。

智能来自 AI 模型（Claude、GPT、Gemini 等），但代理的执行方式、工作空间管理、计算资源分配、行为控制策略——这些基础设施层面的能力，由 Coder Agents 统一提供。

“Intelligence continues to come from the models, but how agents execute, how workspaces and compute are provisioned, and how behavior is controlled become consistent across the organization.” —— Coder 官方博客

这意味着什么？企业可以：

• 自由选择模型：今天用 Claude，明天切换到 GPT-5，后天尝试开源模型——代理的执行框架不变
• 完全自托管：所有代码、数据、执行环境都在企业自己的基础设施内
• 统一治理：模型访问权限、提示词管理、执行策略、可观测性——全部集中管控

核心能力拆解

1. 对话式界面与 API 双通道

Coder Agents 提供了两种交互方式：

• 对话界面：开发者可以直接给代理分配任务——写代码、生成测试、创建 Pull Request
• API 接口：支持从 CI/CD 流水线、GitHub Actions、Slack 等外部系统触发自动化工作流

任务可以前台执行（实时交互），也可以后台运行（异步处理）。

2. 集中化控制平面

这是 Coder Agents 区别于「裸用 Claude Code 或 Cursor」的关键差异点。平台提供了企业级的控制层：

3. 渐进式迁移路径

Coder 没有要求企业「推倒重来」。对于已经在使用 Claude Code、Cursor 或 Codex 的团队，Coder Agents 可以运行在 Coder Workspace 内部，实现平滑过渡：

1. 初期：团队继续使用熟悉的第三方工具
2. 中期：通过 Coder Agents 逐步接管执行环境的管理
3. 后期：完全迁移到自托管的统一平台

与 Cursor Agents 的对比

Cursor 也在 2026 年推出了自托管云代理（Cursor Agents），两者的功能有一定重叠，但设计哲学不同：

Coder 官方也承认两者「有不同的设计优先级」，并非直接的零和竞争。

更广阔的图景：AI 控制平面

Coder Agents 的出现，实际上是「AI 控制平面（AI Control Plane）」这一更大趋势的一部分。类似的解决方案还包括：

• TrueFoundry：提供模型部署、监控、治理的统一平台
• Fiddler：专注于 AI 模型的可解释性与合规审计

这些产品的共同命题是：当 AI 从实验走向生产，企业需要的不只是「更聪明的模型」，而是「更安全、更可控、更可观测」的 AI 基础设施。

对开发者的实际意义

对于一线开发者，Coder Agents 的价值体现在三个层面：

第一，安全感。 代码不再需要通过第三方云端，敏感项目的 AI 辅助成为可能。

第二，灵活性。 不被锁定在单一模型或工具上，可以根据任务特点选择最合适的 AI。

第三，协作效率。 团队共享统一的执行环境和策略，减少「在我机器上能跑」类问题。

结语

Coder Agents 的发布，标志着 AI 编码工具正在从「个人效率玩具」向「企业级基础设施」进化。它的真正创新不在于「又一个 AI 编码代理」，而在于把代理的「智能层」和「执行层」彻底分离，让企业能够在享受 AI 红利的同时，保持对核心资产的完全控制。

对于正在评估 AI 编码工具落地策略的技术负责人，Coder Agents 代表了一个值得认真考虑的方向：不是「选哪个模型」，而是「如何建立一个安全、灵活、可治理的 AI 编码基础设施」。

参考链接：

• Coder Agents 官方博客
• Coder CEO Rob Whiteley 的 LinkedIn 解读
• Cursor 自托管云代理
• InfoQ 原文报道

开篇：一个 Hackday 项目如何改变了我对 AI 的认知

2025 年 5 月的 Shopify Hackday，我尝试做一个 Ruby Gem MCP server，给 Claude Code 提供 AST 导航能力。第一次尝试失败了——Claude 不认识 Prism（Ruby 解析器），文档里也没有例子。

我试了一个”老派”方法：自己先读完 Prism 代码库，然后用 Claude Code 在代码库里学习，再把答案复制粘贴过来。

然后我问了自己一个问题：如果我能把这个过程自动化呢？

我把一个 Claude Code（放在 Prism 代码库里）和主 Claude Code（正在构建 library）通过 MCP 连接起来。结果：两个 agent 一次性完成了任何一个单独 agent 都做不到的事情。

一个关键认知诞生了：两个 agent 协作，胜过任何一个单独 agent。

这个经验最终催生了 Claude Swarm（GitHub 1.4k+ stars）和它的继任者 SwarmSDK。

Shopify 的 AI 采用曲线：从怀疑到全员”氛围编程”

Shopify 的 AI 采用路径很有意思：

2024 年之前：与 OpenAI 签约，内部有聊天工具可用，但大量工程师因为早期 GPT-3.5 的糟糕体验而持怀疑态度。

2024 年：工具向所有人开放——LibreChat、VSCode Copilot、Cursor 等。但渗透率依然不高。

2025 年 2 月转折点：CEO Tobi 发了全员邮件，大意是”在我们雇人之前，先要能证明 AI 做不了这个工作”。这封邮件直接推动了全员 AI 采用。

结果：约 6000 名员工的 Shopify，现在连非工程师都在”氛围编程”（vibe coding）原型产品了。

从”All-in-One”提示词到多代理微服务架构

Shopify 团队观察到一个核心模式：

❌ 旧做法：一个 LLM + 巨大提示词

问题：无关 token 太多
     LLM 会迷路
     效果差

✅ 新做法：多个窄专型 agent

每个 agent 都是某个领域的专家
结果：效果显著提升

SwarmSDK 就是在这一认知下诞生的，核心特性包括：

• 多模型支持：Claude、Gemini、o3 等
• YAML / Ruby DSL 定义 agent：声明式，易维护
• 工作流支持 + 树形结构：复杂任务分解
• 事件钩子：可观测性
• 内置成本追踪：谁在花钱，花了多少
• 插件系统：包括 memory 插件

那些让人头疼的问题

1. 碎片化危机

每个团队都在构建自己的 agent 系统，用不同的框架（LangChain 等），大量重复造轮子。

2. 规模化难题

Shopify 的 AI 团队变成了”AI 特警队”——所有人都有问题来求助。解决方案不是扩大 AI 团队，而是构建赋能工具，让每个团队的 AI 爱好者自己具备构建能力。

3. 非开发者上手难度

YAML 文件、CLI 命令对这些用户来说太复杂了。开发者自己也不想写 YAML 编程。多模型实现的代码当时是”一大坨 hack”，日志记录更是噩梦。

Agent 微服务架构：一个解决碎片化的思路

当前状态（碎片化）：

各团队自己造 agent
      ↓
微服务地狱：
- 网络重试
- 可观测性挑战
- 链路追踪
- 大家只是想通信而已

统一编排策略：

• 所有人用同一种方式定义 agent
• 不需要 MCP/A2A 互相通话
• 导入定义，单进程运行
• Ruby + Fibers：对 I/O 密集的 LLM 工作完美契合（网络请求）

三个核心教训

教训一：”最好的解决方案始于我自己的痛点”

先解决自己的问题。你的真实需求是最强的产品牵引力。

教训二：”把 agent 当成窄专型工具/专家，而不是通才”

• 给 agent 写人物介绍/简介 = 浪费 token
• 除非你想控制 AI 的输出，否则不需要这些
• 用的 token 越少，效果越好

教训三：”不要建 AI 特警队，要建赋能工具”

赋能每个团队的 AI 爱好者——他们最了解自己的领域。

2026 = 有用 Agent 元年？

MCP 上下文膨胀：房间里的大象

当前 MCP 的问题：

• 加工具 = 加 token 到上下文
• 参数描述往往与当前任务无关
• 比如用 Gmail MCP 读邮件 = 浪费 token 在”发邮件”功能上

愿景：每个 token 都精准投放到当前任务。

真实数据：从 22 小时到 7 分钟

Shopify 的实际收益：

所有场景都需要人工复核——不是全自动。

写在最后

Shopify 的多代理系统演进路径，映射了整个行业对 AI 认知的转变：

1. 从怀疑到接受：需要 CEO 级别的推动力
2. 从通才到专才：窄专型 agent 效果远超大一统提示词
3. 从工具到架构：碎片化问题的解法不是更多特警队，而是赋能
4. 从概念到工程：2026 年的关键词是”有用”——而不是”酷”

当你的 agent 开始协作，当你的 token 消耗开始下降，当你团队的 AI 爱好者开始自己构建——你就知道走对路了。

参考来源：What I Learned Building Multi-Agent Systems From Scratch - Paulo Arruda, Staff Engineer at Shopify