HackerNews中文版

嗨，HN，过去几个月，我一直在开发 IntentusNet，这是一个小型的、与语言无关的运行时，用于在代理和工具之间路由“意图”，并提供可选的加密和多种传输方式。 GitHub: <a href="https://github.com/Balchandar/intentusnet" rel="nofollow">https://github.com/Balchandar/intentusnet</a> 它试图解决什么问题我见过的大多数多代理/工具调用设置最终都变成了一堆临时拼凑的胶水： - 每个代理之间自定义的消息格式 - 手工编写的路由和回退逻辑 - 一个地方使用 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,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.GitHub: <a href="https://github.com/Balchandar/intentusnet" rel="nofollow">https://github.com/Balchandar/intentusnet</a>What problem this tries to solveMost multi-agent / tool-calling setups I’ve seen end up as a lot of ad-hoc glue:- 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)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:“Given an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?”What IntentusNet provides (today)At the core it has a few small primitives:- 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 encryptionThere’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.Example usageA minimal flow looks like:- 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 configuredThere’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.Status / what’s missingThis is early-stage:- 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 pointI’d really appreciate feedback on:- 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)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.

Show HN: IntentusNet - 面向多智能体工作流的安全意图路由器和运行时