在传统代理框架中，模型通常被赋予一个预先定义好的工具集合，框架期望模型能够从这些工具中选择最合适的来完成任务。这种静态工具池的设计在简单场景下运行良好，但随着代理能力需求增长，工具数量会急剧膨胀，导致模型面临「工具选择困难」的问题。Tendril 项目提出了一种截然不同的思路 —— 自扩展代理架构，让模型在运行时自主发现、构建并注册新工具，从而实现能力的持续进化。
核心架构：从静态工具池到动态能力注册
Tendril 的设计哲学可以用一句话概括：模型始终只看到三个工具，但它可以访问无限的能力。这三个引导工具分别是 listCapabilities、registerCapability 和 executeCode，它们构成了代理与外部世界交互的基础。当用户提出需求时，代理首先调用 listCapabilities 查询能力注册表，如果找到匹配的工具则直接执行，否则它必须自行构建新工具并通过 registerCapability 注册，然后再次执行。
这种设计从根本上解决了静态工具池的痛点。传统方式下，工具数量随功能增加而线性增长，每个新功能都需要开发者手动定义工具签名、参数模式和执行逻辑。而在 Tendril 的架构中，工具表面保持不变（始终是三个引导工具），但底层的能力注册表会随着使用不断丰富。首次使用时代理可能需要构建工具，再次使用时相同需求已经存在于注册表中，直接复用即可。这种「用进废退」的机制确保了每次会话都比前一次更智能。
引导工具的设计细节
理解 Tendril 的自扩展机制，需要深入分析三个引导工具的具体职责。listCapabilities 负责查询能力注册表，它接收一个搜索查询字符串，返回匹配的工具名称和描述。这个工具的设计非常精简，它只关注「做什么」而不关注「怎么做」，因此模型的搜索行为更加灵活。registerCapability 则负责将新构建的工具写入注册表，它接收工具名称、代码实现和元数据描述。值得注意的是，这个工具的执行结果是持久化的 —— 工具代码被写入文件系统的 tools/ 目录，元数据被写入 index.json，下次启动时这些能力仍然可用。
executeCode 是三个工具中最核心的一个，它负责在沙箱环境中执行代码。Tendril 使用 Deno 作为代码执行引擎，通过 subprocess 方式调用并设置细粒度的权限控制。配置中的 sandbox.timeoutMs 参数控制单次执行的最大时长，默认 45000 毫秒；allowedDomains 参数用于限制网络访问域名列表，空值表示不限制。这种设计确保了即使模型动态构建的工具存在恶意代码或无限循环，运行环境仍然是安全的。
能力注册表的存储结构
Tendril 的能力注册表采用文件系统存储，这使得注册表本身也是可被模型操作的「一等公民」。在 workspace 目录下，index.json 文件存储所有工具的元数据，包括名称、能力描述、触发条件和抑制规则；tools/ 目录存储每个工具的具体实现，均为 TypeScript 文件。触发条件是注册表的一项创新设计 —— 它允许模型定义什么样的对话信号应该激活该工具，这类似于传统意义上的意图匹配，但更加灵活，因为模型可以根据实际使用情况不断调整触发条件。
抑制规则是另一个关键特性，它允许模型定义在什么情况下应该跳过该工具。例如，一个处理日期的工具可能被配置为在输入已经包含结构化日期对象时抑制执行。这种元编程能力使得代理能够更智能地编排工具流，而不需要额外的编排层。当模型发现某个工具在特定场景下表现不佳时，它可以自主更新抑制规则来优化行为。
与静态工具池的本质区别
从工程实践角度看，静态工具池和自扩展架构代表了两种不同的设计范式。静态工具池的优势在于可预测性和可调试性 —— 所有工具在系统启动时就已确定，开发者可以逐一审查其安全性、性能和正确性。但其劣势同样明显：工具数量难以扩展，新功能往往需要修改代理配置并重新部署；模型需要「记住」大量工具签名，当工具数量超过某个阈值时，模型的选择准确率会显著下降。
自扩展架构将工具定义权交给模型本身，这带来了极大的灵活性，但同时也引入了新的工程挑战。首先是安全性问题：模型生成的代码可能包含漏洞或恶意逻辑，Tendril 通过 Deno 沙箱和超时机制来缓解这一风险。其次是一致性问题：模型可能会生成语义重复的工具，或者在不同会话中生成互相冲突的工具定义。Tendril 的解决方案是将注册表暴露为可检查、可编辑的普通文件，用户可以随时介入审查或清理不需要的工具。
从性能角度看，自扩展架构的冷启动时间通常比静态工具池更长，因为首次使用某个能力时模型需要先「生产」工具。但这种一次性的时间成本在长期使用中是可以忽略的，因为注册表会逐渐积累常用能力。对于一个持续使用的代理而言，自扩展架构的工具命中率会随时间不断提升，最终实现接近零成本的工具调用。
工程落地的关键参数
如果要在生产环境中复现 Tendril 的架构设计，有几个关键参数值得关注。首先是沙箱超时设置，Tendril 默认 45000 毫秒，这个值需要根据实际场景调整 —— 计算密集型任务可能需要更长超时，而简单 HTTP 请求则可以缩短以提升响应速度。其次是网络域限制，生产环境应该显式配置 allowedDomains 列表，而不是使用空值来表示「不限制」，这可以防止模型生成的代码意外访问敏感网络资源。
注册表的持久化策略也值得关注。Tendril 使用文件系统存储，这意味着注册表本质上是版本可控的。在团队协作场景下，可以将 index.json 和 tools/ 目录纳入版本控制系统，从而实现工具定义的历史追溯和多版本管理。另一个有价值的实践是定期审计 —— 即使模型可以自主构建工具，定期的人工审查仍然有助于发现潜在的安全风险或设计缺陷。
小结
Tendril 通过三个引导工具和可扩展的能力注册表，实现了代理架构从「预设工具」到「自构建能力」的范式转变。这种设计将工具定义的职责从开发者转移到模型本身，使得代理能够随着使用不断进化。虽然这引入了新的工程挑战 —— 特别是安全性和一致性问题 —— 但通过沙箱隔离、权限控制和文件系统存储等手段，这些挑战是可以被有效管理的。对于需要持续扩展能力的 AI 应用场景，Tendril 的自扩展架构提供了一种值得参考的工程实践方向。