“@tool 不区分简单操作还是完整代理，这个模式让多代理能够直接嵌套。”这是 Strands Agents 文档里对 Agents-as-Tools 的一种描述，也恰好是整个本地实验能成立的关键。最近我刷了不少多代理编排的课程，想试着把中等复杂度的代理模式搬到本机跑通——于是有了这个用 Ollama 在只有 16GB 内存的笔记本上完成的概念验证。

先划个重点：整个方案靠的是一台 16GB 的笔记本、Docker 环境，外加一个勉强塞得下的 gemma4:e2b-it-qat 模型，权重文件略超 4GB。在没有 GPU 加速、不做任何裁剪的情况下，分层代理的路由、隔离和记忆压缩都跑起来了。用来测试的场景是 IT 基础工单自动化——收到一张工单，先判断归属类别（计费、技术、安全），再由专职代理去处理。

打开网易新闻 查看精彩图片

Agents-as-Tools 的架构，核心是 Hub‑and‑Spoke。一个编排器（Orchestrator）握着一组工具，其中某些工具本身就是一个完整的代理。编排器看到的是“调用计费代理”这个工具，返回一段处理结果，中间怎样拆分、怎样核查、怎样生成退款，它一概不知。理解这个上下文隔离，是能跑通本地多代理不炸内存的前提。

这里的上下文隔离不是比喻。从运行循环来看，每次调用代理工具，编排器的循环内部会触发一个全新的、独立的 Agent Loop——不是暂停自己的推理去等结果，而是“看到”一个 tool call 返回了字符串。在字符串生成之前，那个被调用的代理已经在自己的循环里跑完了全部步骤，比如查发票状态、发起退款、生成最终答复。编排器拿到最后那段答复后继续自己的循环，要么再派给其他代理，要么直接给用户。

反过来看，这种隔离也让本地部署变得可控。每次只有一个代理在密集进行模型推理，不会出现多个上下文被动拼接在一起撑爆内存。实验中用 ConversationManager 做了轻量的压缩，编排器只保留最近 10 条工单或交互记录，因此实际占用的上下文远小于理论最坏情况。配合 Ollama 的本地调度，16GB 的运行时余量足够让 gemma4 模型在 Docker 内完成多次往返推理。

还有个容易漏掉的点：工具的描述字串并不是装饰。在 Agents-as-Tools 模式里，每个 @tool 的 docstring 会在运行时被编排器的 LLM 读走，用来判断“这个工单该丢给计费代理还是安全代理”。而 Agent 自身的 description 参数只是元数据，不影响路由。换句话说，描述写得越贴近业务，编排器做出的决策就越准，这跟工具本身到底执行的是简单查询还是完整代理循环并没有关系。

把这一切搬到本地，最大的收获是对分层代理的资源边界有了实感。那台 16GB 的笔记本没有创造奇迹，它只是证明了：当上下文被严格隔离、路由决策被压缩到最核心的提示中时，多代理协作不需要依赖云端弹性算力也能完成基本的自动化拆解。后面的计划是把这套结构搬上 AWS，但至少现在，一台笔记本就能先验证逻辑。