展示HN：IntentusNet - 一个用于多智能体工作流的安全意图路由器和运行时环境
嗨，HN，
在过去的几个月里，我一直在开发IntentusNet，这是一个小型、语言无关的运行时，用于在代理和工具之间路由“意图”，并支持可选的加密和多种传输方式。
GitHub: [https://github.com/Balchandar/intentusnet](https://github.com/Balchandar/intentusnet)
### 这个项目试图解决的问题
我看到的大多数多代理/工具调用设置最终都变成了大量的临时拼凑：
- 各个代理之间的自定义消息格式
- 手动编写的路由和回退逻辑
- 在一个地方使用HTTP，在另一个地方使用WebSocket，可能在其他地方使用ZeroMQ
- 没有一致的追踪或错误模型
- 没有明确的地方添加安全性（加密、来源、身份链）
MCP非常适合描述工具，但它并不试图成为一个运行时或路由器。我想要一些可以在MCP及其他技术栈之下或旁边工作的东西，能够简单回答：
“给定一个意图，哪个代理应该处理它，使用哪种传输方式，采用什么回退机制，以及我们如何安全地封装它？”
### IntentusNet提供的功能（当前）
在核心部分，它有几个小的基本组件：
- **IntentEnvelope** – 结构化消息，包含上下文、元数据、路由选项和标签
- **AgentRegistry** – 内存中代理和能力的注册表（它们处理哪些意图，可选的回退链）
- **IntentRouter** – 选择一个代理，执行它，并在主要代理失败时应用回退
- **Transports** – 可插拔的传输方式，目前包括：
- 进程内（直接路由调用）
- HTTP（带有TransportEnvelope的POST请求）
- WebSocket（双工、异步）
- ZeroMQ（REQ/REP客户端加上简单服务器）
- **Tracing** – 简单的追踪接收器，记录跨度（代理、意图、延迟、状态、错误）
- **EMCL（加密模型上下文层）** – 可选的信封：
- 一个基于HMAC的简单演示提供者
- 一个AES-GCM提供者（AES-256-GCM，base64，身份链）用于真正的加密
此外，还有一个MCP适配器，它接受MCP工具请求（{ name, arguments }），将其封装到IntentEnvelope中，通过IntentusNet路由，并返回MCP风格的结果。这个想法是MCP工具可以通过同一个路由器连接，无论是否使用EMCL。
### 示例用法
一个最小的流程如下：
- 定义具有“summarize.document.v1”、“translate.text.v1”、“store.note.v1”等能力的代理
- 在运行时注册它们
- 使用IntentusClient发送一个带有有效载荷的意图；路由器选择合适的代理，并在配置的情况下处理回退
还有一个小型“助手”风格的设置示例，其中一个类似NLU的代理解析自然语言请求，并向专门的代理（如日历、地图等）发出下游意图，以展示多代理路由的实际应用。
### 状态/缺失的内容
这是一个早期阶段的项目：
- 运行时使用Python；其他SDK（例如C#）尚未准备好
- 编排/工作流层（序列、并行步骤、分支）在RFC中进行了初步勾勒，但仅部分实现
- 文档和示例确实可以改进
- 目前尚未声明生产就绪：这更像是一个结构化的参考实现或起始点
我非常希望能收到关于以下方面的反馈：
- 架构（协议、路由器、传输、EMCL之间的分离是否合理？）
- 这种类型的意图路由器在您正在构建的MCP或基于工具的系统中是否真的有用
- 您期望在这样的运行时中看到的缺失基本组件（超时、背压、更丰富的追踪等）
- 在现实世界的工作流中，小型、传输无关、支持EMCL的路由器将如何提供帮助（或在什么情况下显得过于复杂）
如果您正在使用MCP、多代理设置或安全工具调用，并对这个项目的运作方式有意见，我非常希望听到您的想法——无论是在这里，还是通过GitHub上的问题或PR。
查看原文
Hi HN,<p>Over the last few months I’ve been working on IntentusNet, a small, language-agnostic runtime for routing “intents” between agents and tools, with optional encryption and multiple transports.<p>GitHub: <a href="https://github.com/Balchandar/intentusnet" rel="nofollow">https://github.com/Balchandar/intentusnet</a><p>What problem this tries to solve<p>Most multi-agent / tool-calling setups I’ve seen end up as a lot of ad-hoc glue:<p>- custom message formats between each agent
- hand-rolled routing and fallback logic
- HTTP in one place, WebSocket in another, maybe ZeroMQ somewhere else
- no consistent tracing or error model
- no clear place to add security (encryption, provenance, identity chain)<p>MCP is great for describing tools, but it doesn’t try to be a runtime or router. I wanted something that sits underneath or alongside MCP and other stacks, and just answers:<p>“Given an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?”<p>What IntentusNet provides (today)<p>At the core it has a few small primitives:<p>- IntentEnvelope – structured message with context, metadata, routing options, and tags
- AgentRegistry – in-memory registry of agents and capabilities (which intents they handle, optional fallback chains)
- IntentRouter – picks an agent, executes it, and applies fallback if the primary fails
- Transports – pluggable transports, currently:
- in-process (direct router call)
- HTTP (POST with a TransportEnvelope)
- WebSocket (duplex, async)
- ZeroMQ (REQ/REP client plus simple server)
- Tracing – simple trace sink that records spans (agent, intent, latency, status, error)
- EMCL (Encrypted Model Context Layer) – optional envelope:
- a simple HMAC-based demo provider
- an AES-GCM provider (AES-256-GCM, base64, identity chain) for real encryption<p>There’s also an MCP adapter that takes an MCP tool request ({ name, arguments }), wraps it into an IntentEnvelope, routes it through IntentusNet, and returns an MCP-style result. The idea is that MCP tools can be wired through the same router, with or without EMCL.<p>Example usage<p>A minimal flow looks like:<p>- define agents with capabilities like “summarize.document.v1”, “translate.text.v1”, “store.note.v1”
- register them in the runtime
- use the IntentusClient to send an intent with a payload; the router picks the right agent and handles fallback if configured<p>There’s also an example of a small “assistant”-style setup where an NLU-like agent parses a natural language request and emits downstream intents to specialized agents (calendar, maps, etc.), just to show multi-agent routing in practice.<p>Status / what’s missing<p>This is early-stage:<p>- Runtime is in Python; other SDKs (for example C#) are not ready yet
- Orchestrator / workflow layer (sequences, parallel steps, branching) is sketched out in RFCs but only partially implemented
- Docs and examples can definitely be improved
- No claims of production readiness yet: it’s more of a structured reference implementation or starting point<p>I’d really appreciate feedback on:<p>- the architecture (does the separation between protocol, router, transports, EMCL make sense?)
- whether this kind of intent router is actually useful under MCP or tool-based systems you’re building
- missing primitives you’d expect in a runtime like this (timeouts, backpressure, richer tracing, etc.)
- real-world workflows where a small, transport-agnostic, EMCL-capable router would help (or where it’s overkill)<p>If you’re working with MCP, multi-agent setups, or secure tool calling and have opinions on how this should work, I’d love to hear them—either here or via issues or PRs on GitHub.