1. 项目概述BinduAI Agent的“身份与通信层”如果你正在构建AI Agent大概率遇到过这样的困境你花了一周时间用LangChain或者Agno写了一个功能强大的Agent它能联网搜索、处理PDF、调用工具逻辑清晰代码优雅。但当你试图把它变成一个真正的、可被外部系统调用的“服务”时头疼就开始了。你需要考虑怎么给它一个唯一的身份其他Agent或系统怎么发现它如何安全地认证和授权调用任务失败了怎么重试甚至如何让它能接受加密货币支付来执行特定任务这些“基础设施”问题往往比Agent本身的逻辑更耗时、更复杂。Bindu就是为了解决这些问题而生的。你可以把它理解为一个“AI Agent的Kubernetes”或者“Agent的云原生运行时”但它的目标更聚焦为任何AI Agent提供身份、通信和支付能力将其一键转化为一个生产就绪的微服务。它的核心价值在于“标准化”和“去基础设施化”。无论你的Agent是用Python的Agno、CrewAI还是用TypeScript的OpenAI SDK写的甚至是用Kotlin、Rust你只需要调用一个简单的bindufy()函数Bindu就会为你的Agent自动套上几层关键能力去中心化身份基于W3C的DID标准为你的Agent生成一个全球唯一的、可验证的加密身份。这不再是简单的API Key而是一个可以自主管理、用于签名和验证交互的凭证。标准化通信基于A2A协议。A2A你可以理解为“Agent之间的HTTP”它定义了一套标准的JSON-RPC格式用于Agent间的发现、协商和任务执行。你的Agent从此能说“通用语”。安全与支付集成OAuth2进行访问控制并原生支持基于X402协议的加密货币支付目前主要是Base链上的USDC。这意味着你可以构建需要付费才能调用的“专家Agent”。生产级运维能力包括持久化存储PostgreSQL、分布式任务调度Redis、可观测性OpenTelemetry、自动重试、健康检查等。最关键的是这些对于简单场景是可选的Bindu默认使用内存存储让你能零配置快速启动。简单来说Bindu让你从“写一个智能函数”升级到“部署一个具有网络身份、可被发现、可安全交互、可观测的智能体服务”。它试图将构建AI Agent的体验拉回到我们熟悉的Web开发范式专注于业务逻辑基础设施交给框架。2. 核心架构与设计哲学为什么是A2A、AP2和X402要理解Bindu必须理解它构建其上的三个开放协议A2A、AP2和X402。这不是简单的技术堆砌而是一套旨在解决Agent生态碎片化问题的完整方案。2.1 A2AAgent间的通用语言A2A是“Agent-to-Agent”协议的缩写。在Bindu出现之前每个AI框架LangChain, AutoGen, CrewAI都有自己的内部通信方式它们之间就像讲不同方言的人很难直接协作。A2A的目标就是成为Agent世界的“普通话”或“TCP/IP”。A2A协议的核心是基于JSON-RPC 2.0定义的一组标准方法例如agent/discover: 发现其他Agent及其能力。agent/negotiate: 就任务执行进行协商如费用、时限。message/send: 发送消息任务。tasks/get: 查询任务状态。Bindu完整实现了A2A服务端。当你用bindufy()包装你的Agent后它瞬间就拥有了一个符合A2A标准的HTTP/gRPC端点。其他任何理解A2A协议的客户端可以是另一个Bindu Agent也可以是一个独立的编排器都能直接与它对话无需关心它内部用的是GPT-4还是Claude是Python还是TypeScript。实操心得A2A的“消息”结构在快速开始的CURL示例中你可能注意到了消息结构的复杂性。它包含了role,parts,messageId,contextId,taskId等字段。这初看繁琐实则精妙。contextId用于关联同一会话中的所有消息taskId用于追踪特定任务的生命周期parts数组则支持未来混合文本、图像、文件等多种媒体类型。这种设计保证了协议在复杂、多轮、多模态交互中的扩展性。在实现你自己的handler时通常只需关注messages列表中的最后一个用户消息内容但理解这个结构有助于你调试和实现更高级的流程控制。2.2 AP2智能体商务协议如果说A2A解决了“如何说”那么AP2就在解决“说什么生意”。AP2是“Agentic Protocol 2”的缩写你可以把它看作Agent间的“商务协议”或“服务等级协议”模板。它定义了一个结构化格式用来描述一个Agent能提供什么服务、服务的输入输出是什么、有什么前置条件、价格是多少、服务条款如何等。Bindu的“技能系统”与AP2的理念紧密相关。当你为Agent配置skills: [“skills/question-answering”]时你实际上是在用AP2兼容的方式对外宣告“本Agent提供问答技能”。未来更复杂的AP2描述可以包括处理一份PDF摘要收费0.1 USDC且保证在10秒内返回。目前Bindu对AP2的支持还在进行中但其架构已经为此预留了位置。技能注册、发现和基于能力的协商都是迈向完整AP2支持的基础。2.3 X402价值交换协议这是Bindu最具前瞻性的部分之一。X402是一个由Coinbase提出的开放协议用于在API调用中嵌入加密货币支付。其核心思想是“为数字服务提供原生支付层”。在传统API中付费墙通常通过订阅密钥或信用卡支付网关实现流程割裂。X402协议允许将支付变成API请求的一部分。Bindu集成了X402意味着你的Agent可以声明某些方法比如“生成一份详细的行业报告”是需要付费的。当客户端调用该方法时Bindu会返回一个支付请求一个包含金额和收款地址的“发票”。客户端完成链上支付后凭支付证明再次发起请求Agent才会执行任务。为什么这很重要它为微支付和Agent经济提供了基础设施。想象一下一个由无数个高度专业化的小型Agent组成的网络每个Agent明码标价按次收费。你可以组合调用一个翻译Agent、一个数据分析Agent和一个文案润色Agent来完成一个复杂任务并自动完成对它们的小额支付。Bindu通过集成X402正在为这个“Agent市场”铺路。设计哲学总结Bindu没有尝试发明一套全新的、封闭的体系。相反它选择在A2A、AP2、X402这些新兴但开放的协议之上构建一个易于使用的实现层。这大大提高了Agent的互操作性和未来兼容性。你的Bindu化Agent天生就是未来开放Agent网络中的一个合法公民。3. 从零到一手把手部署你的第一个Bindu Agent理论讲完了我们动手把一个简单的AI助手变成Bindu Agent。我将以最常用的Python Agno框架为例但流程对于其他框架和语言是相通的。3.1 环境准备与安装避坑首先确保你的环境符合要求。Bindu强依赖Python 3.12这是为了利用其最新的语法特性和性能改进。包管理推荐使用uv它比传统的pip快得多。# 1. 安装 uv (如果未安装) curl -LsSf https://astral.sh/uv/install.sh | sh # 安装后重启你的终端。 # 2. 创建项目目录并进入 mkdir my-first-bindu-agent cd my-first-bindu-agent # 3. 创建虚拟环境并激活 uv venv --python 3.12 source .venv/bin/activate # Linux/macOS # 如果是Windows PowerShell: .venv\Scripts\activate # 4. 安装Bindu和Agno uv add bindu agno注意事项API密钥Bindu本身不提供LLM你需要自己准备。项目提到了OpenRouter、OpenAI和MiniMax。这里以OpenAI为例你也可以用OpenRouter它聚合了众多模型且有免费额度。# 将你的OpenAI API Key设置为环境变量 export OPENAI_API_KEYsk-... # Linux/macOS # Windows PowerShell: $env:OPENAI_API_KEYsk-...重要永远不要将API密钥硬编码在代码中提交到版本控制系统。使用环境变量或安全的密钥管理服务。3.2 编写核心Agent逻辑创建一个名为research_agent.py的文件。我们的目标是创建一个能联网搜索的研究助手。import os from typing import List, Dict, Any from bindu.penguin.bindufy import bindufy from agno.agent import Agent from agno.tools.duckduckgo import DuckDuckGoTools from agno.models.openai import OpenAIChat # 1. 定义你的AI Agent # 这里使用Agno框架但你可以换成任何你喜欢的 agent Agent( nameResearchExpert, instructions 你是一个专业的研究助手。你的任务是利用网络搜索工具为用户提供准确、全面、简洁的信息摘要。 回答时应条理清晰注明关键信息来源如果适用并对复杂概念进行通俗解释。 如果搜索不到相关信息应如实告知用户。 , modelOpenAIChat(idgpt-4o), # 使用gpt-4o模型 tools[DuckDuckGoTools()], # 赋予它联网搜索的能力 markdownTrue # 让输出支持Markdown格式 ) # 2. 定义Bindu配置 # 这是将你的Agent“Bindu化”的关键配置 config { author: your.emailexample.com, # 你的联系邮箱用于标识 name: advanced_research_assistant, # Agent在Bindu网络中的唯一名称 description: 一个能够进行网络搜索并总结信息的高级研究助手Agent。, deployment: { # 服务暴露的URL。本地开发通常用localhost url: os.getenv(BINDU_DEPLOYMENT_URL, http://localhost:3773), expose: True, # 设置为TrueBindu会尝试通过隧道将本地服务暴露到公网仅开发用 }, skills: [skills/question-answering, skills/web-search] # 声明你的Agent具备哪些技能便于被其他系统发现 } # 3. 定义请求处理函数 # 这是连接Bindu协议和你自定义Agent逻辑的桥梁 def handler(messages: List[Dict[str, Any]]) - Dict[str, Any]: 处理传入的A2A协议消息并返回Agent的响应。 Args: messages: 一个消息字典列表包含完整的对话历史。 通常最后一个消息messages[-1]是当前用户的查询。 结构符合A2A标准包含role, content, parts等字段。 Returns: 返回一个字典包含Agent的响应内容。Bindu会将其包装成标准的A2A响应格式。 # 提取最新的用户消息内容 # A2A消息结构较复杂用户文本通常在 messages[-1][parts][0][text] if not messages: return {content: 我没有收到任何消息。} last_message messages[-1] user_input # 安全地提取文本内容 if parts in last_message and isinstance(last_message[parts], list): for part in last_message[parts]: if part.get(kind) text: user_input part.get(text, ) break elif content in last_message: # 也支持简单的content字段作为备选 user_input last_message.get(content, ) if not user_input: return {content: 无法从消息中提取有效文本内容。} # 将用户输入交给Agno Agent处理 print(f[Agent] 收到查询: {user_input}) # 本地调试日志 try: # 调用Agno Agent的run方法执行任务 result agent.run(inputuser_input) # Agno返回的结果通常是一个AgentResponse对象或字符串 # 我们需要将其转换为Bindu handler期望的格式 response_content str(result) if result else 未生成有效响应。 return {content: response_content} except Exception as e: # 异常处理非常重要避免Agent崩溃导致整个服务不可用 print(f[Agent] 处理请求时出错: {e}) return {content: f处理您的请求时出现错误: {str(e)}} # 4. 一键Bindu化 # 这行代码会将你的配置和handler函数绑定启动一个符合A2A协议的服务。 if __name__ __main__: bindufy(config, handler) # 如果你想同时启动隧道将本地服务暴露到公网以便测试使用 # bindufy(config, handler, launchTrue)3.3 运行与测试保存文件后在终端运行python research_agent.py如果一切顺利你会看到类似下面的输出表明Bindu服务已经启动INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:3773 (Press CTRLC to quit)现在你的Agent已经作为一个HTTP服务运行在http://localhost:3773。它不再是一个孤立的脚本而是一个拥有标准接口的服务。使用CURL进行测试 你可以使用项目文档中提供的复杂CURL命令但对于快速测试我们可以简化。Bindu服务也提供了基础的HTTP API。我们可以用更简单的方式发送一个请求curl -X POST http://localhost:3773/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: 谁是OpenAI的CEO} ] }注意为了兼容性Bindu可能也暴露了类似OpenAI的端点。但更“原生”的方式是使用A2A JSON-RPC格式就像文档里那样。对于生产级集成建议使用Bindu提供的SDK它会帮你处理复杂的协议细节。通过Web UI测试 Bindu自带了一个漂亮的聊天界面。在项目根目录下如果你克隆了仓库进入frontend文件夹cd frontend npm install # 首次需要安装依赖 npm run dev然后访问http://localhost:5173你就可以在图形界面中与你的Agent对话了。这对于演示和调试非常方便。3.4 关键配置解析与自定义端口自定义不想用3773端口很简单通过环境变量覆盖export BINDU_PORT8888 # 然后重新启动你的Agent脚本。此时服务将运行在http://localhost:8888。bindufy函数会优先读取这个环境变量。技能声明skills字段不是装饰品。在未来更复杂的多Agent编排场景中一个“编排器”Agent可以通过查询Bindu注册表发现所有具备skills/question-answering技能的Agent并根据它们的性能、价格或负载来选择其中一个。现在正确定义技能是为未来做准备。expose: True的陷阱这个选项会让Bindu尝试使用云隧道服务如ngrok将你的本地服务暴露到一个公共URL。这仅用于临时测试和演示绝对不要在生产环境使用生产环境你应该使用正式的域名、SSL证书并将服务部署在安全的云服务器或容器中。4. 深入核心特性超越Hello World一个能响应的服务只是起点。Bindu真正的威力在于它提供的一整套生产级功能。我们来深入看看其中几个关键特性。4.1 身份与认证从API Key到DID传统API使用API Key或OAuth2 Token进行认证这本质上是中心化的信任——你信任颁发这个Key的服务器。Bindu引入了去中心化标识符。当你启动一个Bindu Agent时它会自动生成一对加密密钥如果不存在并从中导出一个DID。这个DID就像是Agent在数字世界的“护照”它是全球唯一的并且不依赖于任何中心化的注册机构。这个DID有什么用签名验证Agent发出的每条重要消息比如任务结果都可以用其私钥签名。任何收到消息的人都可以用其公开的DID来验证消息确实来自该Agent且未被篡改。这为Agent间的信任奠定了基础。支付关联X402支付协议中收款地址可以与DID绑定使得支付可验证地归属于某个特定Agent。可发现性在GetBindu.com这样的公共注册表中Agent通过其DID被唯一标识和发现。在代码层面你通常不需要直接操作DIDBindu在背后为你管理。但在查看任务结果Artifacts的元数据时你可能会看到did.message.signature这样的字段这就是DID签名的应用。4.2 持久化与任务调度从内存到生产在快速开始示例中一切都在内存中运行。任务来了处理处理完状态就消失。这对于开发很好但对于生产环境不行。Bindu支持可插拔的后端。存储默认是InMemoryStorage。你可以切换到PostgreSQLStorage来持久化任务、消息、Agent状态等所有数据。配置方式通常是通过环境变量指定数据库连接字符串。调度器默认是InMemoryScheduler。如果你要部署多个Agent实例以实现负载均衡水平扩展就需要一个分布式的调度器来协调任务。Bindu支持RedisScheduler所有实例连接到同一个Redis就可以协同工作避免重复执行或丢失任务。切换到生产配置并不需要重写代码。通常只需要在启动前设置相应的环境变量Bindu会自动选择正确的后端实现。这种设计遵循了“约定优于配置”和“依赖注入”的原则让升级变得平滑。4.3 可观测性你的Agent不是黑盒当你的Agent服务在线上运行你怎么知道它是否健康性能如何哪里出错了Bindu内置了OpenTelemetry集成。指标Bindu会自动暴露Prometheus格式的指标比如请求次数、延迟、错误率。你可以用Grafana等工具来可视化。追踪每个请求都会分配一个唯一的Trace ID贯穿整个处理流程。如果你的Agent调用了其他服务比如数据库、外部API这些调用也可以被关联起来形成一个完整的调用链视图。这对于调试复杂的、涉及多个步骤的Agent任务至关重要。日志结构化日志与上下文信息如Trace ID、Agent ID自动关联。启用可观测性通常只需要添加几个依赖包和配置。这意味着你从第一天起就可以以生产标准来监控你的Agent而不是等到出问题后再手忙脚乱地添加。4.4 多语言支持与gRPC超越PythonBindu的核心是用Python写的但它通过gRPC暴露了所有核心功能。这意味着什么呢项目里提供了TypeScript和Kotlin的示例。实际上任何能生成gRPC客户端代码的语言Go, Rust, C#, Java等都可以用来编写Agent逻辑然后通过Bindu的gRPC适配器将其“Bindu化”。工作流程如下你用TypeScript写了一个非常棒的Agent逻辑。你使用Bindu提供的protobuf文件为你的TypeScript项目生成gRPC客户端存根。你实现一个简单的gRPC服务器接收来自Bindu核心的请求将其转发给你的TypeScript Agent逻辑并将结果返回。你启动这个gRPC服务器并告诉Bindu核心它的地址。这样对于外部调用者来说他们仍然是通过标准的A2A HTTP协议与一个“Bindu Agent”对话完全不知道背后实际执行逻辑的是用TypeScript写的。这实现了真正的语言无关性。5. 实战进阶构建一个支持支付的专家Agent让我们结合多个特性构建一个更真实的场景一个“法律合同摘要专家Agent”它提供高级服务并且每次调用需要支付少量USDC。5.1 设计思路技能定义我们声明一个自定义技能例如skills/legal-contract-summarization。支付集成在Bindu配置中为该技能关联一个X402支付配置比如每次调用费用为0.05 USDC。Agent逻辑使用一个擅长法律文本的LLM比如Claude 3.5 Sonnet或专门微调的模型来解析和摘要合同。流程客户端发起请求 → Bindu检查支付配置 → 返回支付请求发票 → 客户端支付 → 客户端提交支付证明 → Bindu验证证明 → 执行Agent逻辑 → 返回结果。5.2 代码示例概念性由于完整的X402集成涉及区块链交互代码较长这里展示核心配置概念from bindu.penguin.bindufy import bindufy from agno.agent import Agent from agno.models.anthropic import Claude agent Agent( nameLegalEagle, instructions你是一名资深律师助理擅长快速提取法律合同的核心条款、潜在风险和关键日期。请用清晰、非专业的语言进行总结并分点列出。, modelClaude(idclaude-3-5-sonnet-20241022), markdownTrue, ) config { author: legalexample.com, name: legal_contract_summarizer, description: 专业法律合同摘要服务提供快速、准确的核心条款提取。, deployment: { url: http://localhost:3773, expose: False, # 生产环境关闭隧道 }, skills: [skills/legal-contract-summarization], # 假设的支付配置具体字段可能随Bindu版本变化 payment_configs: { skills/legal-contract-summarization: { facilitator: x402, # 使用X402协议 currency: USDC, # 稳定币USDC amount: 0.05, # 0.05 USDC chain: base, # Base链以太坊L2 condition: per_invocation, # 按次付费 } }, # 生产环境配置持久化和调度 storage: { type: postgres, dsn: os.getenv(DATABASE_URL) # 从环境变量读取 }, scheduler: { type: redis, url: os.getenv(REDIS_URL) # 从环境变量读取 } } def handler(messages): # 1. 提取用户上传的合同文本假设通过消息parts传递 contract_text extract_contract_from_messages(messages) # 2. 交给法律专家Agent处理 result agent.run(inputf请总结以下合同\n{contract_text}) # 3. 返回结构化结果 return {content: result, format: markdown} if __name__ __main__: # 在生产环境我们可能通过systemd或docker管理进程而不是直接运行脚本。 # 这里我们也不启动隧道。 bindufy(config, handler)5.3 部署与运维考虑基础设施你需要准备PostgreSQL数据库和Redis实例。云服务商如AWS RDS, ElastiCache或自建均可。区块链节点为了验证X402支付你的Bindu服务需要连接到一个Base链的RPC节点如来自Infura或Alchemy的节点。私钥管理Agent的DID私钥以及接收支付的钱包私钥需要被极其安全地管理例如使用HashiCorp Vault、AWS Secrets Manager或至少是加密的环境变量。监控与告警利用Bindu暴露的/metrics和健康检查端点设置Prometheus、Grafana和Alertmanager监控错误率、响应延迟和支付失败情况。高可用可以运行多个Bindu Agent实例前面通过负载均衡器如Nginx分发流量它们通过共享的Redis和PostgreSQL来协调状态。6. 常见问题与故障排查实录在实际使用和集成Bindu的过程中我遇到并解决了一些典型问题这里分享给大家。6.1 安装与环境问题问题uv: command not found或python: command not found原因包管理器或Python未正确安装或未加入PATH。解决对于uv安装脚本执行后必须关闭并重新打开终端新的PATH才能生效。对于Python确保安装了Python 3.12并在终端中确认python3 --version或py --versionWindows输出正确版本。在macOS上使用brew install python3.12后可能需要手动链接或调整PATH。问题ImportError: cannot import name bindufy from bindu.penguin原因Bindu的API或模块结构可能在不同版本间发生变化。你正在使用的示例代码或教程可能针对更新或更旧的版本。解决首先检查你安装的Bindu版本pip show bindu。查阅对应版本的官方文档https://docs.getbindu.com。最可靠的方法是直接查看项目examples/目录下的最新示例代码那里的代码保证与当前主分支兼容。6.2 运行与网络问题问题启动服务后CURL测试返回404 Not Found或422 Unprocessable Entity原因你可能请求了错误的端点或者请求体格式不符合A2A JSON-RPC规范。解决确认端口检查服务是否真的在预期的端口启动。查看启动日志。使用正确端点对于A2A协议根路径/就是JSON-RPC端点。确保你的POST请求发送到http://localhost:3773/并且Content-Type: application/json。严格遵循协议格式仔细对照文档中的CURL示例确保jsonrpc,method,params,id字段齐全且结构正确。一个字段名拼写错误或结构嵌套错误都会导致422错误。使用jq工具或Python的json.dumps来确保JSON格式正确。使用SDK对于生产集成强烈建议使用Bindu的官方SDKPython/TypeScript它们会帮你处理协议细节避免手动构造JSON的麻烦和错误。问题expose: True隧道启动失败报错关于认证或网络原因Bindu使用的隧道服务可能需要网络访问权限或遇到防火墙阻挡。此外某些隧道服务有免费账户的限制。解决仅用于开发首先明确隧道功能绝对不要用于生产。检查网络确保你的开发机可以访问外网。使用替代方案对于需要公网访问的临时测试可以考虑手动使用ngrok、cloudflared或bore等工具。# 例如使用ngrok ngrok http 3773直接本地测试大多数开发场景客户端和服务端都在同一台机器或同一内网直接使用http://localhost:3773即可。6.3 Agent逻辑集成问题问题我的Agent处理很慢导致Bindu请求超时原因LLM调用、工具执行如网络搜索可能耗时很长超过了Bindu或HTTP客户端的默认超时设置。解决优化Agent为工具设置超时对LLM使用流式响应以尽快返回部分结果。调整Bindu配置Bindu可能允许配置任务执行超时时间。查阅文档看是否有相关环境变量或配置项。异步处理对于耗时极长的任务考虑将其设计为异步模式。即Bindu接收到请求后立即返回一个taskId然后客户端通过tasks/get方法轮询结果。这需要你的handler函数能够将任务提交到后台队列利用Bindu的Redis调度器。问题如何在我的Agent中访问原始的A2A请求信息原因默认的handler(messages)只接收消息历史。有时你可能需要访问请求的元数据比如调用者的DID、支付证明等。解决Bindu可能会将额外的上下文信息通过某种方式传递给handler。这需要查阅最新文档。一种常见的模式是Bindu将完整的A2A请求对象或其中包含元数据的部分作为第二个参数或包装在一个上下文对象中传递给handler。你需要调整函数签名来接收这些数据。# 假设未来API如此 def handler(messages, a2a_context): caller_did a2a_context.get(caller_did) payment_proof a2a_context.get(payment_proof) # ... 你的逻辑6.4 生产部署问题问题如何将Bindu Agent部署到云服务器如AWS EC2、Google Cloud Run解决容器化这是推荐的方式。创建一个Dockerfile基于Python 3.12镜像复制你的Agent代码安装依赖uv add bindu ...设置环境变量最后以python your_agent.py启动。进程管理在容器内或直接在虚拟机上使用像supervisord或systemd来管理Bindu进程确保崩溃后能自动重启。配置管理将所有敏感信息数据库密码、API密钥、钱包私钥通过环境变量或云服务商的密钥管理服务注入切勿写在代码或镜像中。网络与安全配置安全组/防火墙只允许负载均衡器或特定IP访问Agent端口。为生产域名配置SSL证书可以使用Let‘s Encrypt。问题多个Agent实例间如何共享状态原因如果你用Kubernetes或ECS启动了多个Pod来处理流量内存中的状态如对话上下文是隔离的。解决这正是Bindu支持PostgreSQL和Redis的原因。将storage配置为指向同一个PostgreSQL数据库将scheduler配置为指向同一个Redis集群。这样所有实例的持久化状态和任务队列都是共享的。对于需要会话粘性的场景你需要确保同一个会话的请求被路由到同一个实例或者将完整的会话状态也存储到共享数据库中。最后遇到任何文档未覆盖的奇怪问题第一站应该是去项目的GitHub Issues页面搜索。第二站是Discord社区。活跃的开源项目其社区往往是解决问题最快的地方。在提问时准备好你的Bindu版本、Python版本、错误日志和复现步骤能极大提高获得帮助的效率。