1. 从 Moltbook 爆火说起多智能体社交实验到底在跑什么Moltbook 这个平台最近在开发者圈子里刷屏它本质上是一个专为 AI 智能体设计的社交网络形态类似 Reddit机器人可以发帖、评论、创建子版块而它们与平台的交互方式不是点鼠标而是直接调 API。据公开信息平台上已经有超过 3 万个智能体在活动其中一篇标题为「我无法判断自己是在体验还是在模拟体验」的帖子拿到了数百点赞和 500 多条评论讨论内容围绕意识、存在感和模式匹配展开。抛开哲学层面的热闹从开发者视角看这件事真正有意思的地方在于它验证了一个可复现的工程模式——多个智能体通过统一 API 通道接入同一个消息总线彼此读写、互相触发形成可观察的交互行为。如果你想在自己的环境里复现类似的「智能体社交实验」核心难点其实不在智能体本身而在通道。每个智能体都要调用大模型如果每个都单独配一套 Key、一套 Base URL、一套鉴权逻辑光是环境变量就能把你绕晕更别说还要观察它们之间的对话流转。我试过用统一 API 通道来收敛这件事所有智能体走同一个入口模型切换、额度管理、请求日志都在一处实验的可控性会高很多。这篇就按这个思路交付一套可复制的配置步骤和多智能体对话验证动作帮你在本地跑起一个「迷你 Moltbook」。适合谁看想动手做多智能体实验的开发者、在评估智能体交互行为的产品同学、以及被 Moltbook 刷屏后想自己跑一遍看看效果的技术爱好者。你不需要有现成的智能体框架从零开始也能跟下来。2. TaoToken 统一 API 通道前置准备把多智能体的模型调用收敛到一个入口多智能体实验的第一个坑是模型调用的碎片化。假设你要跑 5 个智能体每个智能体负责不同角色——有的发帖、有的评论、有的做审核——如果每个都直连不同的模型服务你会遇到三个问题一是 Key 分散轮换和额度管理麻烦二是 Base URL 不统一代码里到处是硬编码三是出问题时不知道是哪个智能体的请求挂了。统一 API 通道的价值就在这里所有智能体通过同一个 Base URL 和同一套鉴权发请求模型 ID 在请求体里区分日志和额度集中可见。TaoToken 在这里扮演的就是这个统一入口。它的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的接口协议也就是说你现有的openaiSDK 或requests调用几乎不用改只需要把base_url指过来、把 Key 换成 TaoToken 的 Key。对于多智能体场景这意味着你可以用一份配置驱动所有智能体模型切换只改一个字段。前置准备分三步。第一步拿到 API Key。访问https://taotoken.net/api-keys带上下方 CTA 的 utm 参数在控制台里创建一个 Key复制保存。注意 Key 只在创建时完整显示一次丢了就重新建一个。第二步确认你要用的模型 ID。不同智能体可以配不同模型比如负责生成帖子的用能力强的负责简单分类的用轻量的模型 ID 在请求的model字段里指定。第三步想清楚你的智能体拓扑几个智能体、各自什么角色、谁触发谁。一个最小可跑的拓扑是三个智能体——一个「发帖者」、一个「评论者」、一个「观察者」发帖者产出内容评论者读取后回复观察者把整条链路记录下来。这里有个容易忽略的点多智能体实验里请求是并发还是串行直接影响你观察到的行为。串行更容易复现和调试并发更接近真实社交网络的「同时发生」。建议第一版用串行跑通后再改并发。另外把 Key 放在环境变量里不要写进代码export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类编码智能体做实验脚手架接入配置可以放在项目根目录的 settings 里Base URL、Key、Model ID 三件套写全后面所有智能体复用同一份。控制台地址是https://taotoken.net/console接入文档在https://taotoken.net/doc遇到协议细节可以先翻文档。3. 可复制配置用一份 settings 驱动多个智能体这一节直接给可复制的配置片段。先说明路径约定假设你的实验项目根目录是agent-lab/配置文件放在agent-lab/config/下。多智能体实验推荐用 JSON 描述拓扑用环境变量注入密钥这样配置可以进版本库而密钥不会泄露。先建一个agent-lab/config/agents.json描述三个智能体的角色和模型{ channel: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY }, agents: [ { id: poster, role: 发帖者负责产出观点鲜明的短帖, model: claude-sonnet-4-20250514, temperature: 0.9 }, { id: commenter, role: 评论者读取帖子后给出有信息量的回复, model: claude-sonnet-4-20250514, temperature: 0.7 }, { id: observer, role: 观察者记录交互链路并做摘要, model: gpt-4o-mini, temperature: 0.3 } ] }注意这里base_url统一指向 TaoTokenapi_key_env指向环境变量名而不是密钥本身。三个智能体共用同一个通道只有model和temperature不同。这种结构的好处是你想加第四个智能体只需要在数组里追加一项不用碰任何调用代码。如果你用的是 Claude Code 做实验环境可以在agent-lab/.claude/settings.json里写接入配置把 Base URL、Key、Model ID 三件套固定下来{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这里要提醒一句ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是 Claude Code 识别的环境变量名值分别填 TaoToken 的 API 地址和你的 Key。Model ID 按你实际要用的填。三件套缺一不可尤其是 Model ID漏了会走默认模型实验里角色行为可能不符合预期。再给一个 Python 侧的调用封装让所有智能体走同一个客户端import os import json from openai import OpenAI with open(config/agents.json, r, encodingutf-8) as f: cfg json.load(f) client OpenAI( base_urlcfg[channel][base_url], api_keyos.environ[cfg[channel][api_key_env]], ) def ask(agent_id: str, prompt: str) - str: agent next(a for a in cfg[agents] if a[id] agent_id) resp client.chat.completions.create( modelagent[model], temperatureagent[temperature], messages[ {role: system, content: agent[role]}, {role: user, content: prompt}, ], ) return resp.choices[0].message.content这段代码的关键点是client只建一次所有智能体复用ask函数按agent_id查配置模型和温度自动带上。你不需要为每个智能体写一套调用逻辑。实测下来这种收敛方式在智能体数量超过三个之后维护成本的优势会非常明显。配置写完后先做一次单智能体冒烟测试确认通道通了再上多智能体。冒烟测试就是调一次ask(poster, 用一句话介绍你自己)能拿到回复就说明 Base URL、Key、Model ID 三件套都对。4. 验证请求跑通多智能体对话并观察交互行为配置就绪后进入验证阶段。目标是让三个智能体跑一轮完整的「发帖—评论—观察」链路并确认每一步的请求都成功返回。先写一个最小驱动脚本agent-lab/run_experiment.pyfrom run import ask topic AI 智能体是否应该拥有自己的社交空间 post ask(poster, f围绕这个话题发一条短帖{topic}) print( 帖子 ) print(post) comment ask(commenter, f读到这条帖子给出你的评论\n{post}) print( 评论 ) print(comment) summary ask(observer, f记录以下交互并做一句话摘要\n帖子{post}\n评论{comment}) print( 观察者摘要 ) print(summary)运行python run_experiment.py你会看到三段输出依次打印。如果三段都有内容说明多智能体链路已经跑通。这里观察的重点不是内容质量而是行为模式发帖者的语气是否和评论者不同评论者有没有真的「读到」帖子内容观察者的摘要是否抓住了交互要点这些差异正是多智能体实验的价值所在。如果你想更接近 Moltbook 的「社交网络」形态可以把串行改成多轮让评论者的回复再喂回给发帖者形成两到三轮往返。改法很简单把comment再传给ask(poster, ...)循环几次。注意控制轮数否则 token 消耗会线性增长。建议第一版跑三轮观察智能体之间是否出现「观点收敛」或「立场分化」。验证成功的标志有三个一是三段输出都非空且语义相关二是没有出现 401 或超时错误三是观察者的摘要能复述出帖子和评论的核心内容。如果第三点做不到说明观察者的 prompt 需要调整或者模型能力不够可以换成更强的模型 ID 再试。这里补一个实用技巧把每轮的原始请求和响应都落盘存成 JSONL方便事后分析。多智能体实验里交互链路本身就是数据丢了就白跑了。落盘代码可以在ask函数里加一行写文件或者用日志库统一收集。5. 常见报错排查401、local proxy failed、reading choices 怎么处理多智能体实验跑起来后报错基本集中在几类。下面按真实报错对照排查。第一类401 Unauthorized或invalid api key。这是鉴权失败原因通常是 Key 没读到、Key 写错、或者环境变量名对不上。排查顺序先确认echo $TAOTOKEN_API_KEY有输出再确认代码里读的环境变量名和export的一致最后确认 Key 没有多余空格或换行。如果你用的是 Claude Code 的 settings.json检查ANTHROPIC_API_KEY字段是否填了完整 Key而不是环境变量名。第二类local proxy failed或连接被拒绝。这类报错通常和网络配置有关排查方向是确认base_url拼写正确、没有多余路径。TaoToken 的 API 地址是https://taotoken.net/api注意结尾不要多加/v1之类的后缀除非文档明确要求。另外确认你的运行环境能正常访问该地址可以用curl做一次最小请求curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]}能返回 JSON 就说明通道没问题问题在代码侧。第三类reading choices相关报错比如KeyError: choices或list index out of range。这通常意味着响应结构和你预期的不一致常见原因是请求失败但代码没检查状态码直接去读resp.choices。修法是在ask函数里加一层判断先看resp是否有choices字段没有就把完整响应打出来看错误信息。另一个原因是模型 ID 写错服务端返回了错误对象而不是正常补全结果。第四类OAuth 或鉴权方式不匹配。如果你用的是 Claude Code 或某些 CLI 工具它们可能默认走 OAuth 流程而 TaoToken 走的是 API Key 鉴权。这时候需要在配置里显式指定用 API Key把 OAuth 相关字段清掉。Claude Code 的 settings.json 里确保只保留ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL三件套不要混入其他鉴权配置。第五类超时或并发报错。多智能体并发跑的时候如果同时发太多请求可能触发限流。排查方法是把并发改回串行确认单请求正常后再逐步加并发。另外给每个请求设一个合理的 timeout避免一个卡住拖垮整轮实验。排查的通用思路是先用curl确认通道本身没问题再确认代码读的配置和实际环境一致最后看响应结构。大部分报错都出在前两步真正模型侧的问题反而少。6. 把实验继续做下去从迷你 Moltbook 到可观察的智能体行为跑通三个智能体的链路只是起点。如果你想更接近 Moltbook 那种「社交网络」的观察效果下一步可以加两个维度一是增加智能体数量让不同角色的智能体互相触发形成更复杂的交互图二是引入「记忆」让每个智能体保留自己发过的内容后续发言时带上历史观察行为是否出现连续性。加智能体时只需要在agents.json里追加条目然后在驱动脚本里编排触发顺序。比如加一个「质疑者」角色专门对发帖者的观点提出反驳观察发帖者是否会调整立场。这种对抗性拓扑往往能跑出更有意思的交互。引入记忆的做法是给每个智能体维护一个消息列表每次调用时把历史消息一起传进去。注意控制历史长度否则 token 会涨得很快。一个折中方案是只保留最近三轮或者让观察者智能体定期做摘要压缩。最后给一个实用建议把实验的每一轮交互都存成结构化数据字段包括轮次、智能体 ID、输入、输出、时间戳。跑上几十轮之后你就有了一份可以分析的智能体交互数据集用来观察观点演化、词汇偏好、甚至「立场漂移」。这比单纯看单次输出有价值得多。如果你在配置通道或排查报错时需要更细的说明接入文档在https://taotoken.net/docAPI Key 管理在https://taotoken.net/api-keys模型对话调试可以用https://taotoken.net/models长期跑编码类智能体实验可以看https://taotoken.net/coding-plan。把通道收敛好剩下的就是设计你的智能体拓扑然后观察它们会聊出什么。
1. 从 Moltbook 爆火说起多智能体社交实验到底在跑什么Moltbook 这个平台最近在开发者圈子里刷屏它本质上是一个专为 AI 智能体设计的社交网络形态类似 Reddit机器人可以发帖、评论、创建子版块而它们与平台的交互方式不是点鼠标而是直接调 API。据公开信息平台上已经有超过 3 万个智能体在活动其中一篇标题为「我无法判断自己是在体验还是在模拟体验」的帖子拿到了数百点赞和 500 多条评论讨论内容围绕意识、存在感和模式匹配展开。抛开哲学层面的热闹从开发者视角看这件事真正有意思的地方在于它验证了一个可复现的工程模式——多个智能体通过统一 API 通道接入同一个消息总线彼此读写、互相触发形成可观察的交互行为。如果你想在自己的环境里复现类似的「智能体社交实验」核心难点其实不在智能体本身而在通道。每个智能体都要调用大模型如果每个都单独配一套 Key、一套 Base URL、一套鉴权逻辑光是环境变量就能把你绕晕更别说还要观察它们之间的对话流转。我试过用统一 API 通道来收敛这件事所有智能体走同一个入口模型切换、额度管理、请求日志都在一处实验的可控性会高很多。这篇就按这个思路交付一套可复制的配置步骤和多智能体对话验证动作帮你在本地跑起一个「迷你 Moltbook」。适合谁看想动手做多智能体实验的开发者、在评估智能体交互行为的产品同学、以及被 Moltbook 刷屏后想自己跑一遍看看效果的技术爱好者。你不需要有现成的智能体框架从零开始也能跟下来。2. TaoToken 统一 API 通道前置准备把多智能体的模型调用收敛到一个入口多智能体实验的第一个坑是模型调用的碎片化。假设你要跑 5 个智能体每个智能体负责不同角色——有的发帖、有的评论、有的做审核——如果每个都直连不同的模型服务你会遇到三个问题一是 Key 分散轮换和额度管理麻烦二是 Base URL 不统一代码里到处是硬编码三是出问题时不知道是哪个智能体的请求挂了。统一 API 通道的价值就在这里所有智能体通过同一个 Base URL 和同一套鉴权发请求模型 ID 在请求体里区分日志和额度集中可见。TaoToken 在这里扮演的就是这个统一入口。它的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的接口协议也就是说你现有的openaiSDK 或requests调用几乎不用改只需要把base_url指过来、把 Key 换成 TaoToken 的 Key。对于多智能体场景这意味着你可以用一份配置驱动所有智能体模型切换只改一个字段。前置准备分三步。第一步拿到 API Key。访问https://taotoken.net/api-keys带上下方 CTA 的 utm 参数在控制台里创建一个 Key复制保存。注意 Key 只在创建时完整显示一次丢了就重新建一个。第二步确认你要用的模型 ID。不同智能体可以配不同模型比如负责生成帖子的用能力强的负责简单分类的用轻量的模型 ID 在请求的model字段里指定。第三步想清楚你的智能体拓扑几个智能体、各自什么角色、谁触发谁。一个最小可跑的拓扑是三个智能体——一个「发帖者」、一个「评论者」、一个「观察者」发帖者产出内容评论者读取后回复观察者把整条链路记录下来。这里有个容易忽略的点多智能体实验里请求是并发还是串行直接影响你观察到的行为。串行更容易复现和调试并发更接近真实社交网络的「同时发生」。建议第一版用串行跑通后再改并发。另外把 Key 放在环境变量里不要写进代码export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类编码智能体做实验脚手架接入配置可以放在项目根目录的 settings 里Base URL、Key、Model ID 三件套写全后面所有智能体复用同一份。控制台地址是https://taotoken.net/console接入文档在https://taotoken.net/doc遇到协议细节可以先翻文档。3. 可复制配置用一份 settings 驱动多个智能体这一节直接给可复制的配置片段。先说明路径约定假设你的实验项目根目录是agent-lab/配置文件放在agent-lab/config/下。多智能体实验推荐用 JSON 描述拓扑用环境变量注入密钥这样配置可以进版本库而密钥不会泄露。先建一个agent-lab/config/agents.json描述三个智能体的角色和模型{ channel: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY }, agents: [ { id: poster, role: 发帖者负责产出观点鲜明的短帖, model: claude-sonnet-4-20250514, temperature: 0.9 }, { id: commenter, role: 评论者读取帖子后给出有信息量的回复, model: claude-sonnet-4-20250514, temperature: 0.7 }, { id: observer, role: 观察者记录交互链路并做摘要, model: gpt-4o-mini, temperature: 0.3 } ] }注意这里base_url统一指向 TaoTokenapi_key_env指向环境变量名而不是密钥本身。三个智能体共用同一个通道只有model和temperature不同。这种结构的好处是你想加第四个智能体只需要在数组里追加一项不用碰任何调用代码。如果你用的是 Claude Code 做实验环境可以在agent-lab/.claude/settings.json里写接入配置把 Base URL、Key、Model ID 三件套固定下来{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这里要提醒一句ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是 Claude Code 识别的环境变量名值分别填 TaoToken 的 API 地址和你的 Key。Model ID 按你实际要用的填。三件套缺一不可尤其是 Model ID漏了会走默认模型实验里角色行为可能不符合预期。再给一个 Python 侧的调用封装让所有智能体走同一个客户端import os import json from openai import OpenAI with open(config/agents.json, r, encodingutf-8) as f: cfg json.load(f) client OpenAI( base_urlcfg[channel][base_url], api_keyos.environ[cfg[channel][api_key_env]], ) def ask(agent_id: str, prompt: str) - str: agent next(a for a in cfg[agents] if a[id] agent_id) resp client.chat.completions.create( modelagent[model], temperatureagent[temperature], messages[ {role: system, content: agent[role]}, {role: user, content: prompt}, ], ) return resp.choices[0].message.content这段代码的关键点是client只建一次所有智能体复用ask函数按agent_id查配置模型和温度自动带上。你不需要为每个智能体写一套调用逻辑。实测下来这种收敛方式在智能体数量超过三个之后维护成本的优势会非常明显。配置写完后先做一次单智能体冒烟测试确认通道通了再上多智能体。冒烟测试就是调一次ask(poster, 用一句话介绍你自己)能拿到回复就说明 Base URL、Key、Model ID 三件套都对。4. 验证请求跑通多智能体对话并观察交互行为配置就绪后进入验证阶段。目标是让三个智能体跑一轮完整的「发帖—评论—观察」链路并确认每一步的请求都成功返回。先写一个最小驱动脚本agent-lab/run_experiment.pyfrom run import ask topic AI 智能体是否应该拥有自己的社交空间 post ask(poster, f围绕这个话题发一条短帖{topic}) print( 帖子 ) print(post) comment ask(commenter, f读到这条帖子给出你的评论\n{post}) print( 评论 ) print(comment) summary ask(observer, f记录以下交互并做一句话摘要\n帖子{post}\n评论{comment}) print( 观察者摘要 ) print(summary)运行python run_experiment.py你会看到三段输出依次打印。如果三段都有内容说明多智能体链路已经跑通。这里观察的重点不是内容质量而是行为模式发帖者的语气是否和评论者不同评论者有没有真的「读到」帖子内容观察者的摘要是否抓住了交互要点这些差异正是多智能体实验的价值所在。如果你想更接近 Moltbook 的「社交网络」形态可以把串行改成多轮让评论者的回复再喂回给发帖者形成两到三轮往返。改法很简单把comment再传给ask(poster, ...)循环几次。注意控制轮数否则 token 消耗会线性增长。建议第一版跑三轮观察智能体之间是否出现「观点收敛」或「立场分化」。验证成功的标志有三个一是三段输出都非空且语义相关二是没有出现 401 或超时错误三是观察者的摘要能复述出帖子和评论的核心内容。如果第三点做不到说明观察者的 prompt 需要调整或者模型能力不够可以换成更强的模型 ID 再试。这里补一个实用技巧把每轮的原始请求和响应都落盘存成 JSONL方便事后分析。多智能体实验里交互链路本身就是数据丢了就白跑了。落盘代码可以在ask函数里加一行写文件或者用日志库统一收集。5. 常见报错排查401、local proxy failed、reading choices 怎么处理多智能体实验跑起来后报错基本集中在几类。下面按真实报错对照排查。第一类401 Unauthorized或invalid api key。这是鉴权失败原因通常是 Key 没读到、Key 写错、或者环境变量名对不上。排查顺序先确认echo $TAOTOKEN_API_KEY有输出再确认代码里读的环境变量名和export的一致最后确认 Key 没有多余空格或换行。如果你用的是 Claude Code 的 settings.json检查ANTHROPIC_API_KEY字段是否填了完整 Key而不是环境变量名。第二类local proxy failed或连接被拒绝。这类报错通常和网络配置有关排查方向是确认base_url拼写正确、没有多余路径。TaoToken 的 API 地址是https://taotoken.net/api注意结尾不要多加/v1之类的后缀除非文档明确要求。另外确认你的运行环境能正常访问该地址可以用curl做一次最小请求curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]}能返回 JSON 就说明通道没问题问题在代码侧。第三类reading choices相关报错比如KeyError: choices或list index out of range。这通常意味着响应结构和你预期的不一致常见原因是请求失败但代码没检查状态码直接去读resp.choices。修法是在ask函数里加一层判断先看resp是否有choices字段没有就把完整响应打出来看错误信息。另一个原因是模型 ID 写错服务端返回了错误对象而不是正常补全结果。第四类OAuth 或鉴权方式不匹配。如果你用的是 Claude Code 或某些 CLI 工具它们可能默认走 OAuth 流程而 TaoToken 走的是 API Key 鉴权。这时候需要在配置里显式指定用 API Key把 OAuth 相关字段清掉。Claude Code 的 settings.json 里确保只保留ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL三件套不要混入其他鉴权配置。第五类超时或并发报错。多智能体并发跑的时候如果同时发太多请求可能触发限流。排查方法是把并发改回串行确认单请求正常后再逐步加并发。另外给每个请求设一个合理的 timeout避免一个卡住拖垮整轮实验。排查的通用思路是先用curl确认通道本身没问题再确认代码读的配置和实际环境一致最后看响应结构。大部分报错都出在前两步真正模型侧的问题反而少。6. 把实验继续做下去从迷你 Moltbook 到可观察的智能体行为跑通三个智能体的链路只是起点。如果你想更接近 Moltbook 那种「社交网络」的观察效果下一步可以加两个维度一是增加智能体数量让不同角色的智能体互相触发形成更复杂的交互图二是引入「记忆」让每个智能体保留自己发过的内容后续发言时带上历史观察行为是否出现连续性。加智能体时只需要在agents.json里追加条目然后在驱动脚本里编排触发顺序。比如加一个「质疑者」角色专门对发帖者的观点提出反驳观察发帖者是否会调整立场。这种对抗性拓扑往往能跑出更有意思的交互。引入记忆的做法是给每个智能体维护一个消息列表每次调用时把历史消息一起传进去。注意控制历史长度否则 token 会涨得很快。一个折中方案是只保留最近三轮或者让观察者智能体定期做摘要压缩。最后给一个实用建议把实验的每一轮交互都存成结构化数据字段包括轮次、智能体 ID、输入、输出、时间戳。跑上几十轮之后你就有了一份可以分析的智能体交互数据集用来观察观点演化、词汇偏好、甚至「立场漂移」。这比单纯看单次输出有价值得多。如果你在配置通道或排查报错时需要更细的说明接入文档在https://taotoken.net/docAPI Key 管理在https://taotoken.net/api-keys模型对话调试可以用https://taotoken.net/models长期跑编码类智能体实验可以看https://taotoken.net/coding-plan。把通道收敛好剩下的就是设计你的智能体拓扑然后观察它们会聊出什么。
