你的编码代理不需要更大的上下文窗口。它需要同事。

Source: Dev.to

我已经使用 Claude Code 构建了数月。它真的很令人印象深刻——直到你的代码库变得足够大，以至于代理开始在自己的上下文中淹没。

1 M‑token 的上下文窗口听起来很大，但如果把它喂给一个真实项目——几百个文件，六层深的导入链，配置散布在 YAML 和 .env 文件中——你就会遇到瓶颈。响应变慢，质量下降，成本上升，因为模型花了一半的 token 在阅读与你的问题无关的代码。

本能上会等更大的上下文窗口，但这不是正确的解决方案。更聪明的 CTO 并不意味着 CTO 必须亲自审查每一行代码。

Enter AgentHub – 一个轻量级的 Python 库，它将你的代码库拆分为专门的代理，将查询路由到合适的代理，并在问题跨越多个领域时让它们协作。

实际中的问题

假设你正在开发一个 Django 项目。你向你的编码助手询问：

“支付流程是如何运作的？”

此时，助手必须处理你的认证中间件、URL 路由、序列化器、支付服务、Stripe Webhook、数据库模型、测试夹具……所有这些都被加载到同一个上下文窗口中，而其中大部分是无关的。

真正的答案可能只分布在 4‑5 个文件、跨越 2‑3 个模块，但助手事先并不知道这一点。它会把所有内容都吞进去，耗尽 token，并给出一个稀释的答案，因为它一次要记住太多信息。

这是一种路由问题，而不是容量问题。

第1层：自动生成的域代理

首个洞察是，你的代码库已经告诉你自然边界在哪里。

• 文件夹 → 域
• 文件 → 职责
• 导入图 → 依赖

何不利用这种结构自动创建代理？

AgentHub 的 build 命令会扫描你的仓库并生成 Tier B 代理——每个逻辑域一个，预先加载仅属于它的文件。

from agenthub import AgentHub
from agenthub.auto import discover_all_agents

hub, summary = discover_all_agents("./my-project")
response = hub.run("How does user authentication work?")

工作原理

1. 文件树遍历 – 映射文件夹结构、大小和语言。
2. 导入图构建 – 解析 import 语句以了解，例如 api/views.py → services/auth.py → models/user.py。
3. 代理创建 – 构建聚焦的代理，每个代理的上下文窗口仅加载其域内的文件。

当查询到来时，路由器会根据每个代理的关键字和域对查询进行打分，然后将其分发给最佳匹配的代理：

• src/api/ 代理 → API 相关问题
• src/models/ 代理 → 模式（schema）相关问题

没有浪费的 token。

Tier A 代理（可选）是为代码结构无法推断的业务逻辑手工编写的，例如了解利润规则的定价代理或了解 KPI 定义的分析代理。

Layer 2：跨领域问题的 DAG 团队

单代理路由在针对范围明确的问题（例如“UserSerializer 类的作用是什么？”）时表现出色。但在跨领域的问题（例如“结账流程是如何端到端工作的？”）上就会失效，因为答案分布在 API、服务、模型和支付等多个层次。

对于这些情况，AgentHub 会启动一个 DAG 团队：

1. 复杂度分类器 检测到查询跨越多个领域。
2. 分解器 确定相关的代理。
3. 导入图 提供它们之间的依赖边。
4. 执行 – 独立的代理并行运行；有依赖的代理顺序执行。
5. 合成器 将结果合并为连贯的答案。

该 DAG 是基于导入图 按查询 构建的，因此协作结构反映了实际代码的连接，而非想象中的架构。

Source: …

第3层：并行会话

当开发者说“在工具栏上添加保存按钮 并且 构建一个时间序列图表组件”时，这实际上是两个相互独立、涉及完全不同文件的任务。如今，编码代理会顺序处理它们。为什么不并行执行呢？

AgentHub 的 并行会话 层：

• 将多部分请求拆解为独立任务。
• 使用导入图分析文件之间的重叠情况。
• 对于不相交的任务，在不同的 Git 分支上启动独立的 Claude Code 会话。
• 每个会话的作用域仅限于与其任务相关的文件。
• 合并协调器 将这些分支合并，运行测试，并捕获仅靠 Git 无法检测的语义冲突。

可以把它想象成 公司模型：当一家初创公司只有两个人时，CTO（你的编码代理）无所不知。随着公司规模扩大，你会雇佣专才（Tier B 代理），每个人负责知识的某一片段，而 CTO 则负责协同合作。

概览

当部门规模变大时，你会组织团队（DAG 团队）。当出现全公司范围的倡议时，各团队会在各自的轨道上同步工作，并在边界处进行对齐。

合并步骤是最棘手的地方。文本冲突很容易处理——git 能自动解决。语义冲突则更困难：两个分支可以顺利合并，却破坏了彼此的假设。针对这类情况，AgentHub 会在合并后运行测试套件。如果测试失败，解决代理会检查失败原因，追溯到冲突的更改，并进行修复或上报给开发者。

当前状态

AgentHub 版本为 v0.1.0。核心的自动代理生成、DAG 团队以及并行会话基础设施均已实现。它以 Python CLI 形式发布，并通过 MCP 与 Claude Code 集成，使得代理直接在终端中表现为工具。

当前状态

• 自动代理生成 – 表现良好；指向一个代码仓库即可得到有用的代理。
• DAG 团队 – 功能可用，但需要对分解器提示进行调优。
• 路由层 – 决定哪个代理处理查询仍需手动微调，以在不同代码库中可靠运行。
• 并行会话 – 大多仍在实验阶段；git 编排已相当稳固，但语义冲突解决仍有待完善。

我暂时不公开此项目。还有不少粗糙之处，我希望在发布之前先把路由和代理质量提升到满意的水平。不过，我仍然分享其架构，因为核心理念——使用导入图划分代理边界、基于 DAG 的协作以及公司增长模型——无论实现方式如何都很有价值。

如果你在使用编码代理时遇到上下文限制，欢迎分享你的解决方案。

由 John 构建。整个 AgentHub 代码库是与 Claude 合作开发的——这感觉恰如其分地递归。