企业官网建设流程全解析

1. 为什么编程工具要先解决“协作”问题

1.1 三四个AI工具放一起，反而不会干活了

如果你和我一样，电脑里同时装着 Copilot、Claude Code、Cursor，甚至还有一两个本地起的 OpenAI 兼容接口，大概会察觉一个很微妙的现象：工具越多，能感觉到的“智能”并没有变多，反而变量变多了。

原因是每个工具各有一套上下文。在 Copilot 里讨论过一轮的技术方案，到了 Claude Code 那边是完全陌生的；Claude Code 花几分钟把项目结构摸清楚，Cursor 又得重新学一遍。更麻烦的是，两个工具会同时写文件。我印象最深的一次：一边让 Copilot 修一个 bug，一边让 Claude Code 重构同一个函数，等我切回编辑器，看到的就是两边互相覆盖后的“缝合怪”代码，bug 没修好，重构也没完成。

这不能怪任何一个工具，问题出在缺少一层调度。

“智能体基建”这个词这两年高频出现，很多人可能觉得只是名词游戏。但等你的电脑里真的有两个以上能干活的 AI 编程智能体时，就会明白：问题从来不在单个模型强不强，而在于谁来决定每个模型在什么时候干什么。这个“谁来决定”的调度层、上下文同步层、协议转换层，就是基建。Herdr 在我这儿的定位，恰好就是这一层。

1.2 从 I2C 总线的多路复用说起

做嵌入式的朋友听到“多路复用”应该会立刻想到 I2C。I2C 总线上挂一堆传感器，但同一组 SDA/SCL 线上，同一时刻只能有一个设备在通信。多路复用器做的事情，就是把总线控制权分配好，让各个从设备协调地共享那对信号线，彼此不干扰。

智能体多路复用，逻辑上完全一样。

模型接口、工具调用、上下文会话，本质上都在竞争同一个“总线”——也就是你的编排层。两个智能体不能同时把内容写进同一个文件，就像两个传感器不能同时占住 I2C 总线。复用器要做的是排队、分配、隔离信号。Herdr 做的就是这样一件事：把多个编程工具挂到同一个入口，按路由规则分配使用时间，对外暴露一个稳定接口，对内各自干活时不互相踩踏。

这个思路落到软件工程里，解决的是三个很实际的问题：

• 会话复用：多个工具共享同一个任务上下文，不需要每换一个工具就重新解释一遍背景。
• 连接复用：底层模型 API 的连接和鉴权统一管理，不用每个工具各建一条长连接。
• 能力复用：代码补全、重构、解释、生成测试这些能力被拆开，按需调度，而不是所有工具重复实现。

1.3 为什么在 2026 年这个节点，基建会突然变成主线

很多圈内人都在说：智能体行业正在从“概念演示”走向“工程化落地”。我的体感是，大家已经不太关心“智能体能不能写代码”，而是关心“智能体能不能稳定地写出符合团队规范的代码”。前者靠模型，后者靠基础设施。

以前你花一个下午在某个 IDE 里配好一个 Agent，能跑通一个 demo 就算成功。但要把 AI 编程真正放进日常迭代，你得面对上下文同步、工具链冲突、成本控制、权限审计这些问题——这些全是基建活，不是模型活。

这也是我想写这个“智能体基建系列”的原因：多路复用不是一个新功能，它不生产新的智能体能力，但能把已有的能力有效地组织起来。Herdr 在我的实践里，就是干净利落的那一层组织者。

2. Herdr 的多路复用到底复用了什么

2.1 三层含义：会话复用、上下文复用、能力复用

先说一个容易混淆的点。很多人以为“多路复用”就是把多个大模型接口塞到一个网关后面，谁调用就给谁发请求。这确实是一部分，但不是全部。

Herdr 的处理方式，我拆成三个层面理解：

第一层，连接多路复用。这层最接近 I2C 的原始语义。假定你有三种工具：编辑器里的 Copilot、终端里的 Claude Code、本地 DeepSeek 接口。它们在同一个项目里干活，如果各自直连 API，等于每把椅子上都单独拉了一根网线。Herdr 在中间做一个连接收敛，所有下行请求从同一个连接池走，统一鉴权、统一限流。好处是省连接、方便做预算控制，出问题排查时也有一个集中的日志入口。

第二层，会话/上下文复用。这是智能体场景里最值钱的部分。Copilot 看到了你刚写的函数，Claude Code 也应该知道这个函数的存在；本地模型在帮你总结昨天的聊天记录，Copilot 的补全也应该有那个上下文输入。Herdr 会维护一个共享的“会话上下文区”，每个工具在开始工作前，先从这个区域拉取当前任务的相关背景；工作结束后，把变更写回去。这样各工具从物理隔离变成逻辑隔离，但认知上是一体的。

第三层，能力复用。代码补全、生成测试、做 Code Review、解释报错、重构结构……这些能力不应该绑死在某个工具里。在 Herdr 的配置里，每个后端会被标成“擅长什么”，路由时按能力匹配。比如补全请求给 Copilot，重构请求给 Claude Code，解释性问答给本地模型。每个工具干自己最擅长的那部分，整个链条的效率才会上去。

2.2 路由怎么写：让每个模型干它最擅长的事

多路复用最核心的参数，我认为是“路由规则”。Herdr 让我觉得顺手的原因，是它对任务做了比较细致的分类，而不是简单粗暴地按工具名分发。

我当前用的这套路由逻辑：

路由不是全有或全无，而是带权重的“优先倾向”。有些任务本地模型其实也能做，但质量差一些，我会把权重调低，让它作为兜底而不是首选。比如 qa 这种对话型任务，用本地模型省成本，又不会因为延迟打断写代码的思路；但真要深度分析一个复杂问题，我还是会切到 Claude Code 那条路，靠权重和关键词规则组合实现。

经验是：路由规则要从“少而粗”开始。一开始我只分了两条，一条给补全，一条给对话。用了一周，发现重构请求老是跑错后端，才拆出 plan 和 refactor。规则不是设计出来的，是用出来的。

2.3 配置示例与参数解读

Herdr 的配置是 YAML，整体结构有一点像网关配置和 CI 工作流的结合体。最关键的是 routes 部分，下面是我后台里一段精简过的核心配置：

herdr: gateway: port: 9080 auth_token: ${HERDR_TOKEN} session: ttl: 3600 share_mode: global storage: sqlite routes: - name: complete backend: copilot model: default weight: 40 max_tokens: 512 context: ["task-snippet", "file-tags"] - name: plan backend: claude-code model: claude-sonnet weight: 50 max_tokens: 4096 context: ["repo-summary", "task-plan"] - name: qa backend: local-deepseek base_url: http://127.0.0.1:8080/v1 model: deepseek-chat weight: 50 max_tokens: 1024 context: ["chat-history"]

几个值得展开讲一下的参数：

• ttl是会话上下文的存活时间。设成 3600 秒，意味着工具之间共享的上下文在任务执行后可以保留一小时。设太长，代码更新后上下文会过期；设太短，频繁失效又要重新同步。
• context数组决定这个路由接入时会从共享区拉哪些类型的上下文。repo-summary是仓库结构摘要，task-plan是当前任务计划，file-tags是最近改动的文件标签。按需拉取，不要所有路由都拉全量，否则上下文会迅速膨胀失真。
• weight不是严格的百分比，更像是一个倾向指数。遇到模棱两可的任务，Herdr 会优先选权重高的后端；但如果你在某一轮明确指定了后端，它也绝对服从。

这套配置我花了一个小时左右才调得比较满意，核心是摸清了“什么任务别发给什么后端”：本地小模型别发重构任务，Copilot 别发超长上下文的分析任务。

3. 实操落地：把 Copilot、Claude Code、本地模型接进同一套上下文

3.1 最小部署方案：一个二进制加一个配置

Herdr 的安装比我想象中轻。它本质上是一个本地服务，不需要额外数据库，用 SQLite 存会话状态就够了。我这台开发机上用的是 Docker 方式：

docker run -d \ --name herdr \ -p 9080:9080 \ -v /etc/herdr:/etc/herdr \ -v /var/herdr-data:/data \ -e HERDR_TOKEN=$(openssl rand -hex 16) \ herdr/herdr:latest

如果不想用 Docker，直接下载对应架构的二进制文件，跑一遍herdr init，它会在当前目录生成一个herdr.example.yml，编辑后herdr serve -c herdr.yml就起来了。二进制方式适合那些本来就用 sdwebui、ollama 这类工具管理本地模型的人，路径统一，进程管理更直观。

我建议第一次做的时候先不用 Docker，直接用二进制跑本地模式。因为你会频繁改配置和重启，容器的端口映射和挂载反而增加变量。等配置稳定了，再迁到 Docker 或 systemd 服务里。

3.2 把 Copilot 接进来的实际操作

接入编程工具时，最容易被绕晕的就是“Herdr 如何与 IDE 里的 Copilot 对话”。

我这里用的模式是：IDE 里装一个支持自定义 OpenAI 兼容服务端的扩展，把base_url指向http://127.0.0.1:9080/v1，api_key填生成好的HERDR_TOKEN。Herdr 收到请求后，再根据路由规则把请求转发到真正的 Copilot Bridge。Copilot 那边也不用改，它只认你原来配置的 key。

这一步的关键在于：Herdr 不是替代 Copilot，而是把自己伪装成“一个更大的 Copilot”。对 IDE 来说，它和平时连官方服务没有任何区别；对 Copilot 官方服务来说，它只是多了一个用户。

当然这里有个现实问题：直接用官方 Copilot 的 token 做二次转发，容易被服务端判定为异常访问。我自己的做法是，把“补全”这一类任务用官方 Copilot 接口跑，把“重构、解释、测试生成”这些重任务全部导向 Claude Code 和本地模型。因为补全请求短、依赖强，适合官方接口；重任务反而不要再挤占那份额度。

3.3 接入 Claude Code 与本地模型

Claude Code 的接入稍微特殊一点。它不是裸的 API 服务，而是带自己的一套终端交互和工作区的程序。Herdr 有一个 adapter 模式，可以把你配置好的 Claude Code 命令包成一个后端服务，Herdr 和它之间走标准输入输出流。

大概长这样：

- name: claude-code adapter: command command: claude args: ["--output-format", "stream-json"] env: ANTHROPIC_AUTH_TOKEN: ${ANTHROPIC_TOKEN} working_dir: /workspace/repo

启动 Herdr 时，它会把这个命令拉起，然后通过管道和 Claude Code 进程交互。这么做有个好处：Claude Code 自己的文件处理能力、MCP 工具调用能力原封不动，Herdr 只负责决定什么时候给它派活、怎么把结果发出去。

本地模型更直接。只要模型服务提供了 OpenAI 兼容接口，Herdr 内置的 provider 就够用：

- name: local-deepseek provider: openai-compatible base_url: http://127.0.0.1:8080/v1 model: deepseek-chat api_key: sk-local

不需要写代码。这也是我当时选 Herdr 的一个重要原因：它预置了 OpenAI 兼容协议，省了我自己封装的时间。

3.4 与 SSE 流式接口的对接经验

编程工具很多都用流式输出，特别是代码生成场景，用户看的是“一行一行吐出来”的效果。Herdr 对外暴露的接口也是 SSE 风格，这里有一个坑，我踩了好几天。

Herdr 在转发流式响应时，把收到的流分块发给前端。但如果后端返回的流里面带了非 JSON 的日志行，解析会异常，表现为“响应到一半突然卡住”或者“第一次生成正常、第二次就空白”。

解决方式是加一层流清洗：

async function handleSSE(res, backendStream) { for await (const rawLine of backendStream) { const line = rawLine.toString().trim(); if (!line.startsWith("data:")) continue; try { const data = JSON.parse(line.slice(5).trim()); res.write(`data: ${JSON.stringify(data)}\n\n`); } catch { // 跳过脏数据，不让它打断流 } } res.end(); }

另外一定要处理心跳。SSE 连接如果长时间没有数据推进，网关或代理层会把连接断掉。通常每 15 秒发一个注释行或者 ping 事件，Herdr 自己也支持这个配置，我是直接打开了内置的 keep-alive，避免自己在适配层里额外写定时器。

4. 真正让工具“协作起来”的玩法

4.1 代码评审：不是请一个审查官，而是组一支团队

多路复用配好后，我觉得最有价值的场景是 Code Review。以前我只有一套工具时，依赖它的单次判断；现在我会让两个不同工具评审同一次 PR，再取它们输出的交集和差异。

流程是这样的：

1. 用 Claude Code 扫一遍完整 diff，输出结构性意见，比如模块耦合度、变更影响面。
2. 用本地 DeepSeek 做一次轻量扫查，重点找明显 bug、空指针风险、边界条件缺失。
3. 让 Herdr 把两份意见合并进同一份报告，按“阻塞问题 / 建议优化 / 风格提示”三级分类。

合并逻辑在 Herdr 的context层实现。Claude Code 的分析结果会被写入共享会话区，本地模型拿到这些结果后再做一个融合输出。这样做比单一工具靠谱的原因很简单：不同模型训练的盲区不同，多路复用让你在不牺牲统一视角的情况下，拿到多重视角。

不要迷信“多模型交叉验证”这种说法。我实测下来，两个模型对明显问题通常会达成一致，但真正有价值的是它们各自独有的那部分意见。所以我的习惯是，保留一份“仅 Claude”和一份“仅本地模型”的原始输出，合并报告只是给人类同事快速看的摘要。

4.2 任务分解：规划归规划，执行归执行

复杂的开发任务，多路复用可以配置成一条流水线：规划器、执行器、验证器各司其职。

配置里我新增了这样一组规则：

- name: decompose backend: claude-code roles: [task-plan] - name: implement backend: copilot roles: [task-snippet] - name: verify backend: local-deepseek roles: [task-review]

Decompose 负责把一个含糊需求拆成明确子任务，并把结果写到共享上下文区。Implement 阶段只接收当前子任务的精确描述和文件标签，做实际编码。Verify 阶段再跑一遍静态检查，把问题反馈回任务列表。

这个链路最大的好处是：执行阶段不被全局上下文干扰。Copilot 在补全代码时，只需要看到当前文件相关的几百行上下文；如果非要给它灌入整个项目的所有需求描述，它反而会生成一堆无关代码。多路复用把上下文约束在合适范围，这比单一工具的输出质量提升要明显得多。

4.3 把 MCP、RAG 和编程智能体串起来

接入 MCP 是我最近在玩的方向。Claude Code 本身支持 MCP 服务器，但没有 Herdr 时，MCP 工具只在单独会话里生效。现在 Herdr 把 MCP 工具注册成公共能力，路由规则里可以直接标注某个任务需要调用哪些 MCP 工具。

比如项目里有一套公司内部的 API 文档，我把它做成了 RAG 索引，并通过 MCP 暴露一个检索接口。在 Herdr 的配置里，plan路由会带上这个 MCP 工具，于是 Claude Code 做方案规划时，可以自己去检索最新 API 文档，而不是凭记忆生成过时的建议。

这里我要提醒一句：MCP 工具的调用权限一定要收窄。我在配置里单独限制了 MCP 工具可访问的工作目录，避免 AI 编程智能体为了“完成任务”去读不该读的配置和密钥文件。多路复用把工具连在一起的同时，实际上也把安全半径连在了一起，权限隔离如果没做好，破坏半径会成倍放大。

5. 常见问题与排查实录

5.1 工具改动互相覆盖，文件被“缝合”

这是我在第一节提到过的场景，也是多路复用最容易引发的问题。排查下来，根因是共享上下文里缺少“文件修改锁”。两个任务同时认领了同一个文件的修改权。

我后来在 Herdr 的配置里启用了文件锁：

file_lock: enabled: true owner: task-id timeout: 120

每个任务开始前，Herdr 会检查目标文件是否被占用；占用中就直接拒绝，并返回“文件被 x 任务锁住”。我的经验是把超时设短一点，比如 120 秒，因为编码任务一般不会长时间占用文件，锁太久反而会造成排队积压。

5.2 上下文过期：工具还在按老方案干活

共享上下文最大的副作用，是它会越来越“旧”。我遇到过 Claude Code 在方案里引用的接口已经被 Copilot 改了三次，还在继续按老版本文案往下写。后来我意识到，上下文区里的文件摘要和接口摘要必须带版本标记。

处理方式是给路由加上版本检查：

session: ttl: 3600 version_guard: true

version_guard开启后，如果摘要快照对应的 Git commit 与当前工作区不一致，Herdr 会警告路由任务：上下文已经过期，需要重新生成。刚开始会有点烦，因为频繁触发重新摘要，但用顺手之后，它帮你挡掉了太多“按旧上下文干活”的无用功。

5.3 接口限流和成本控制

多个编程工具共用一个模型后端时，很容易把 API 限额打爆。Herdr 的限流配置和常规网关类似，可以按路由分组设置每分钟请求数。我把本地模型限流设得比较高，因为是内网服务；对外部模型接口，则限制得更严格。

另外我建议不要只看请求次数，要看 token 消耗。重任务（plan、refactor）一次可能消耗几万 token，轻量问答一次才几百。我把不同路由的每日 token 预算单独列出来，Herdr 到预算后会将后续任务降级到本地模型。成本控制这件事，等账单出来再优化就晚了，提前在路由层做配额才是对的。

5.4 SSE 断流、响应不完整

除了前面讲到的脏数据问题，断流还有一个常见诱因：后端超时设置太短。Claude Code 在思考模式或复杂重构中，有时会长时间不输出任何 token。网关层通常有默认的 60 秒无响应断开机制，于是你以为它坏了，其实它只是在思考。

Herdr 对每个上游连接有独立的超时配置，我把它调到了一分钟以上，效果稳定。如果发现某类任务响应特别慢，大概率是上游超时设置和模型思考时间不匹配，这是排查很久才想明白的。

5.5 多路复用后调试复杂度上升

这是所有方案落地后最不情愿面对的问题：调试变得困难。以前一个工具出问题，查它的日志就行；现在请求要经过 IDE 扩展、Herdr 网关、路由后端、模型服务四个环节，链路中任何一环出问题，表面症状却是同一个“代码没生成”。

我的调试方法是，把 Herdr 的日志输出切到结构化模式，并且强制给每个请求带上task-id。日志里所有的转发、丢弃、错误都带着同一个 ID，按 ID 过滤就能串起完整链路。这个习惯是在被“不知道走到哪一步”折磨了几次之后才养成的。多路复用的收益来自共享，代价也在共享——没有链路追踪的共享，就是灾难现场。

6. 我的体会与后续可以做什么

这套 Herdr 配置我从一个临时起意的想法，到变成每天写代码的默认工作流，大概用了两周。最明显的变化不是单次生成变快了，而是上下文同步的烦恼消失了。我不用再记得“这件事我在哪个工具里说过”，因为所有工具都从同一个会话区读取背景。以前那种“换个工具就失忆”的断裂感没了，这个体感变化对我价值很大。

最后分享两个小建议。第一，多路复用是从“一个多余连接”开始的，不要一开始就想把四五个工具全量接进来，先用两个工具跑通一条简单链路，比如 Copilot 做补全、Claude Code 做规划，跑稳了再逐步扩展。第二，配置变更一定要纳入版本管理，herdr.yml和代码一起提交，因为我踩过“生产配置漂移”的坑——本地调试好用的规则，过两周再看已经和文档差了一大截。

下一步我会把 MCP 工具接入面再扩大，把测试生成、数据库 schema 同步这些能力也挂进路由表里。等这个链路再稳定一些，我再写一篇关于“多智能体任务编排”的实操记录出来。智能体基建才开始，后面能玩的东西还很多。