Tianji开源框架：构建多智能体协作社会的技术实践-平芜编程栈

1. 项目概述：当AI学会“社交”，一个开源智能体的新范式

最近在开源社区里，一个名为Tianji的项目引起了我的注意。它来自SocialAI-tianji组织，名字本身就很有意思——“天机”。这可不是什么玄学工具，而是一个旨在让AI智能体（Agent）具备“社交”能力的开源框架。简单来说，它想让单个的AI智能体不再“单打独斗”，而是能够像人类一样，在由多个智能体构成的“社会”中协作、竞争、沟通，共同完成更复杂的任务。

这听起来有点科幻，但背后的逻辑非常务实。我们目前接触的绝大多数AI应用，无论是聊天机器人还是自动化脚本，本质上都是一个“单体”。你给它一个指令，它执行，然后结束。但在真实世界里，解决问题往往需要多方协作。比如，要策划一场线上活动，可能需要市场、设计、开发、运营等多个角色的AI智能体共同参与，它们需要交换信息、协调进度、甚至就方案细节进行“讨论”或“辩论”。Tianji 瞄准的正是这个场景——构建一个多智能体社会模拟与协作平台。

对于开发者、研究者，甚至是企业内部的自动化流程设计者而言，Tianji 提供了一个全新的工具箱。你可以用它来快速搭建一个包含不同角色、不同能力的智能体团队，观察它们如何互动，并优化协作策略。这不仅仅是技术上的炫技，它直接关系到复杂任务自动化、模拟仿真、游戏NPC生态、甚至新型人机交互界面的可能性。如果你对Agent、多智能体系统（MAS）或者自动化工作流感兴趣，Tianji 是一个非常值得深入把玩的“乐高积木”套装。

2. 核心设计理念：从“工具”到“社会成员”的思维转变

2.1 为何需要“社交化”的智能体？

传统的AI模型或智能体，其设计范式是“输入-处理-输出”。它是一个功能强大的“工具”，但缺乏“社会性”。当任务复杂度上升，涉及多个领域知识或需要分阶段推进时，单一智能体要么能力不足，要么设计会变得极其臃肿。

Tianji 的设计哲学基于一个核心洞察：复杂问题的解耦与分工协作，是人类社会高效运转的基石，同样也适用于AI。通过将大任务分解，分配给各有所长的智能体，并让它们通过一套约定的“社交规则”（如通信协议、协作机制）进行交互，可以显著提升系统的鲁棒性、灵活性和可扩展性。

举个例子，一个“自动撰写行业分析报告”的任务。一个单体智能体可能需要同时具备信息检索、数据分析、文案撰写、图表生成等多重能力，且逻辑链条极长，容易出错。而在Tianji的框架下，你可以创建：

研究员Agent：负责搜索和整理最新行业数据与新闻。
分析师Agent：负责处理数据，提炼核心观点和趋势。
撰稿人Agent：根据分析结果，组织语言撰写报告正文。
审阅人Agent：检查报告的逻辑性、准确性和文风。

这些Agent各司其职，并通过消息传递进行协作（例如，研究员将数据发给分析师，分析师将结论发给撰稿人）。这种架构不仅更清晰，也更容易维护和迭代——你可以单独优化“分析师”的算法，而不影响其他部分。

2.2 Tianji框架的核心组件拆解

要理解Tianji如何工作，我们需要拆解它的几个核心抽象层。根据其开源文档和设计，其架构通常包含以下关键部分：

Agent（智能体）：这是系统的基本单位。每个Agent不仅仅是一个LLM的封装，它通常包含：

身份与记忆：一个明确的角色定义（如“前端工程师”、“产品经理”），以及用于存储对话历史、任务上下文和个人知识的记忆模块。
能力集：该Agent可以执行的具体操作，例如调用某个API、运行一段代码、访问特定数据库。在Tianji中，能力通常通过“工具”（Tools）来定义和暴露。
决策引擎：基于当前的目标、接收到的消息和自身记忆，决定下一步该做什么（例如，执行某个工具、向某个Agent发送消息、还是等待）。这部分常由LLM驱动，遵循类似ReAct（Reasoning and Acting）的范式。

环境（Environment）：所有Agent共存的空间。它定义了Agent之间如何发现彼此、如何进行通信（消息总线）、以及如何感知共享的世界状态（例如，一个共享的待办事项列表、一个项目代码库）。环境负责调度Agent的激活顺序，传递消息，并可能提供一些全局服务。

社交协议（Social Protocol）：这是Tianji“社交”属性的核心。它是一套规则，规定了Agent之间交互的礼仪和范式。例如：

协作协议：如何发起一个协作请求？如何分配子任务？如何同步进度？
竞争协议：在资源有限的情况下，多个Agent如何通过“辩论”或“竞标”来决定由谁执行某项任务？
通信原语：消息的格式是什么？（如，必须包含发送者、接收者、意图、内容）。是否支持广播、组播、私聊？

任务与工作流（Task & Workflow）：用户提出的高层级目标。Tianji需要能将一个复杂的自然语言描述的任务，自动或半自动地分解为一系列子任务，并分配给合适的Agent去执行。工作流引擎则负责监控这些子任务的执行状态和依赖关系。

注意：开源项目在快速迭代中，上述组件名称和具体实现可能略有变化，但万变不离其宗，理解这些核心抽象是上手任何多智能体框架的关键。

3. 从零开始：搭建你的第一个多智能体社会

理论说了这么多，我们直接动手，用Tianji来构建一个简单的场景：一个智能团队自动处理用户反馈。假设我们收到一条用户反馈：“手机APP在登录时经常闪退，希望尽快修复，另外建议增加夜间模式。”

我们的目标是创建三个Agent：一个客服Agent负责初步回复和安抚用户，一个技术分析师Agent负责根据反馈内容生成初步的Bug报告或需求标签，一个项目经理Agent负责协调并生成一个简单的处理看板。

3.1 环境准备与基础安装

首先，确保你的开发环境已经就绪。Tianji通常是一个Python框架，强烈建议使用虚拟环境。

# 1. 克隆仓库（请以项目官方仓库地址为准，此处为示例） git clone https://github.com/SocialAI-tianji/Tianji.git cd Tianji # 2. 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 3. 安装依赖 pip install -r requirements.txt

安装过程中最常见的坑是Python版本和深度学习框架（如PyTorch）的版本兼容性问题。Tianji可能依赖较新的Python特性，建议使用Python 3.9+。如果遇到PyTorch安装错误，最好先去PyTorch官网根据你的CUDA版本获取正确的安装命令。

实操心得：对于这类活跃的开源项目，requirements.txt有时可能更新不及时。如果安装失败，可以尝试先安装核心依赖（如openai,langchain等），再根据具体的报错信息逐个解决。查看项目的setup.py或pyproject.toml文件是更可靠的方法。

3.2 定义你的第一个智能体：客服专员

在Tianji中，创建一个Agent通常需要定义它的角色指令（System Prompt）、拥有的工具以及使用的LLM模型。

# 示例代码，展示Tianji可能的Agent定义方式（具体API请以官方文档为准） import tianji as tj from tianji.agents import RoleBasedAgent from tianji.tools import Tool, tool # 首先，定义一个工具：查询知识库（这里用模拟函数） @tool def search_knowledge_base(query: str) -> str: """根据用户问题查询内部知识库，返回相关解决方案摘要。""" # 这里应该是连接向量数据库或ES的代码，此处模拟 knowledge = { "闪退": "常见原因：1.缓存过多 2.APP版本过低 3.系统兼容性问题。建议步骤：清除缓存、更新APP、重启设备。", "夜间模式": "该功能已在开发路线图中，预计下个版本上线。" } for key, value in knowledge.items(): if key in query: return value return "未找到相关解决方案，已转交技术部门深入排查。" # 创建客服Agent customer_service_agent = RoleBasedAgent( name="CustomerService", role_description=""" 你是一名专业的客服专员，负责热情、耐心地处理用户初始反馈。 你的职责： 1. 首先对用户的问题表示理解和歉意。 2. 尝试从知识库中寻找即时解决方案回复用户。 3. 如果无法直接解决，需明确告知用户问题已记录并转交专业团队。 4. 全程保持友好、积极的语气。 """, tools=[search_knowledge_base], # 赋予它查询知识库的工具 llm_model="gpt-3.5-turbo", # 或使用本地模型，如 "Qwen/Qwen2.5-7B-Instruct" memory_size=5, # 保留最近5轮对话记忆 )

关键参数解析：

role_description：这是Agent的“人格”和“职责说明书”。写得越具体，Agent的行为就越可控。要明确告诉它“是什么角色”、“该做什么”、“不该做什么”。
tools：Agent的能力边界。一个没有工具的Agent只能“空谈”，有了工具它才能“实干”。工具函数必须用@tool装饰器声明，并写好文档字符串，这有助于LLM理解何时以及如何使用它。
llm_model：Agent的“大脑”。你可以使用OpenAI API、Azure OpenAI或本地部署的开源模型（需兼容OpenAI API格式）。对于实验和开发，使用gpt-3.5-turbo成本较低且稳定。生产环境考虑成本和数据隐私，可转向本地模型。
memory_size：决定Agent能记住多少上下文。太小可能遗忘关键信息，太大会增加token消耗和成本。需要根据对话复杂度权衡。

3.3 构建多智能体协作环境

单个Agent意义不大，我们需要创建一个环境，让多个Agent入住并能够通信。

# 继续定义技术分析师和项目经理Agent（简化版） tech_agent = RoleBasedAgent( name="TechnicalAnalyst", role_description="你是技术分析师，负责分析用户反馈中的技术问题，将其归类为Bug或Feature Request，并生成简要的技术描述和优先级建议（P0-P3）。", tools=[], # 可以赋予代码分析、日志查询等工具 llm_model="gpt-3.5-turbo", ) pm_agent = RoleBasedAgent( name="ProjectManager", role_description="你是项目经理，负责接收客服和技术分析师的输入，协调资源，并生成一个包含任务标题、描述、负责人、优先级和状态的处理看板项。", tools=[], # 可以赋予创建JIRA Issue、发送邮件等工具 llm_model="gpt-3.5-turbo", ) # 创建一个多智能体环境 from tianji.environments import MultiAgentEnvironment env = MultiAgentEnvironment( name="UserFeedbackProcessingTeam", agents=[customer_service_agent, tech_agent, pm_agent], # 可以配置消息路由规则、冲突解决机制等 ) # 定义工作流：用户反馈 -> 客服 -> 技术分析 -> 项目经理 def feedback_processing_workflow(user_feedback: str): print(f"[用户反馈] {user_feedback}") # 步骤1：客服Agent处理 cs_response = env.execute_agent_action( agent_name="CustomerService", action=f"处理以下用户反馈：{user_feedback}。请先尝试从知识库寻找答案，如果需要移交，请总结问题核心。" ) print(f"[客服回复] {cs_response}") # 假设客服判断需要技术介入，它将问题摘要发送给技术分析师 problem_summary = "用户反馈：登录闪退；需求：增加夜间模式。知识库无法完全解决，需技术分析。" # 步骤2：技术分析师Agent处理 tech_analysis = env.execute_agent_action( agent_name="TechnicalAnalyst", action=f"请分析以下问题：{problem_summary}。请输出分类（Bug/Feature）、简要描述和优先级（P0-P3）。" ) print(f"[技术分析] {tech_analysis}") # 步骤3：项目经理Agent整合 pm_task = env.execute_agent_action( agent_name="ProjectManager", action=f"请根据客服和技术分析的输入，创建一个任务看板项。客服输入：{problem_summary}。技术分析：{tech_analysis}。" ) print(f"[项目经理生成看板] {pm_task}") return pm_task # 运行工作流 result = feedback_processing_workflow("手机APP在登录时经常闪退，希望尽快修复，另外建议增加夜间模式。") print("\n=== 最终处理结果 ===") print(result)

这个简单的例子展示了一个线性工作流。在实际的Tianji框架中，可能会提供更高级的工作流编排器或基于事件的触发机制，允许更复杂的、非线性的交互（例如，技术分析师可能需要向客服追问更多细节）。

4. 深入核心：智能体的“社交”行为如何实现？

让Agent“动起来”并相互交谈，是Tianji这类框架最迷人的部分。这不仅仅是函数调用，而是模拟一种社会行为。

4.1 消息传递与通信机制

Agent之间通过“消息”进行通信。一个设计良好的消息结构至关重要。通常，一条消息会包含：

sender: 发送者ID
recipient: 接收者ID（或广播地址）
content: 消息内容
intent: 消息意图（如request_info,provide_data,coordinate_task），这有助于接收者快速理解该如何处理。
conversation_id: 所属对话链，用于关联上下文。

在环境（Environment）中，会有一个消息总线（Message Bus）或黑板（Blackboard）系统。Agent将消息发送到总线，环境根据路由规则（例如，根据recipient，或根据intent订阅关系）将消息传递给目标Agent。目标Agent的决策引擎（LLM）会结合这条消息和自身的记忆，决定如何响应。

# 一个简化的消息传递模拟 class Message: def __init__(self, sender, recipient, content, intent="inform"): self.sender = sender self.recipient = recipient self.content = content self.intent = intent # 在Agent的决策循环中 def agent_think_and_act(agent, received_messages): context = agent.memory.get_context() + "\n".join([f"From {msg.sender}: {msg.content}" for msg in received_messages]) prompt = f""" {agent.role_description} 当前上下文： {context} 请决定你的下一步行动。你可以： 1. 执行某个工具（格式：TOOL: <tool_name> <arguments>） 2. 发送消息给其他Agent（格式：SEND_TO: <agent_name>, CONTENT: <your message>） 3. 表示任务完成（格式：TASK_COMPLETE: <summary>） 你的决定是： """ response = llm_call(prompt) # 调用LLM # 解析response，执行相应动作

4.2 记忆与上下文管理

每个Agent都有自己的记忆。记忆不仅仅是聊天历史，它可能包括：

短期对话记忆：最近几轮交互的内容。
长期知识记忆：通过向量数据库存储的、关于项目或领域的相关知识。
任务记忆：当前正在执行的任务目标、步骤和已完成的工作。

良好的记忆管理能防止Agent在长对话中迷失，也是实现持续协作的基础。Tianji可能需要集成像LangChain的ConversationBufferMemory、ConversationSummaryMemory或向量存储（如Chroma,FAISS）来构建强大的记忆系统。

实操心得：记忆管理是资源消耗和效果平衡的艺术。全量保存所有历史对话会迅速耗尽LLM的上下文窗口并增加成本。一个实用的策略是“摘要记忆”：定期让LLM对之前的对话进行摘要，只保留摘要和最近几条原始消息。对于需要精确回忆的细节（如数字、代码片段），可以将其存入向量数据库，需要时通过检索增强生成（RAG）的方式召回。

4.3 冲突解决与共识形成

当多个Agent对同一问题有不同意见时（例如，技术分析师认为闪退是“中优先级P2”，而项目经理根据产品节奏认为是“高优先级P1”），就需要冲突解决机制。Tianji可能提供以下几种方式：

权威裁决：指定一个“管理者”Agent（如项目经理）拥有最终决定权。
民主投票：所有相关Agent投票，少数服从多数。
辩论协商：让持不同意见的Agent进行多轮辩论，LLM根据辩论内容生成一个综合结论。
外部仲裁：将冲突提交给一个更高级别的LLM或人类进行裁决。

实现辩论协商是一个高级但有趣的功能。可以创建一个“辩论环境”，让两个Agent围绕一个议题交替发言，并由一个“裁判”Agent或规则来判定何时结束以及结果如何。

5. 进阶实战：构建一个自组织的开源项目协作模拟

让我们挑战一个更复杂的场景：模拟一个开源小团队（前端、后端、测试）协作开发一个“TODO List”应用的功能。我们将尝试让Tianji管理的过程更“自主”。

5.1 场景与Agent定义

目标：实现“为TODO List添加用户身份验证功能”。Agent团队：

ProductOwner (PO)：提出需求，验收成果。
FrontendDev (FE)：负责前端页面和逻辑。
BackendDev (BE)：负责后端API和数据库。
Tester (QA)：负责编写和运行测试。

5.2 实现自主任务分解与认领

我们不想手动编写每一步的工作流，而是希望PO提出需求后，Agent们能自己开会讨论，分解任务，并认领。

# 伪代码/概念展示 def self_organizing_development(initial_request): # 1. PO广播需求 env.broadcast( sender="PO", content=f"新需求：{initial_request}。请FE、BE、QA同学评估并讨论实现方案。", intent="kickoff_meeting" ) # 2. 环境启动一个“讨论回合” discussion_log = env.run_discussion_round( participants=["FE", "BE", "QA"], topic="任务分解与认领", max_turns=6 # 每人最多发言两次 ) # run_discussion_round 会依次激活参与者Agent，让他们基于讨论历史和自身角色发言。 # 3. 从讨论记录中，尝试提取共识的任务列表（这里可以用LLM进行总结提取） task_list = llm_summarize_tasks(discussion_log) # 期望输出类似：[“FE: 创建登录/注册页面组件”， “BE: 设计用户模型和认证API”， “QA: 编写端到端登录流程测试”] # 4. 任务认领（可以模拟一个简单的认领过程） for task in task_list: # 广播任务 volunteers = env.ask_for_volunteers(task) if volunteers: assigned_agent = select_agent(volunteers) # 简单策略：第一个响应的 assigned_agent.accept_task(task) print(f"{task} -> 已分配给 {assigned_agent.name}") else: print(f"{task} -> 无人认领，需要PO协调") # 5. 并行执行与状态同步（简化） # 每个Agent开始执行自己的任务，并通过环境更新状态（如“进行中”、“阻塞”、“已完成”） # 环境可以定期检查所有任务状态，并通知相关方。

这个模拟的关键在于env.run_discussion_round和env.ask_for_volunteers的实现。这需要环境具有更复杂的调度和状态管理能力，Agent也需要更高级的决策逻辑（例如，判断一个任务是否与自己的技能匹配）。

5.3 集成外部工具与现实世界交互

要让模拟更有价值，Agent不能只“空谈”，还得能“实操”。这就需要集成外部工具。

FE Agent：可以集成一个代码生成工具，调用如pico.css或React组件库的API，生成前端代码片段。
BE Agent：可以集成一个工具，调用FastAPI或Django的脚手架命令，或者直接操作数据库模型。
QA Agent：可以集成一个测试框架工具（如pytest），让它能生成并运行测试用例。

# 示例：为BE Agent集成一个“创建API端点”的工具 @tool def create_fastapi_endpoint(endpoint_name: str, methods: list, request_model: dict, response_model: dict) -> str: """根据给定参数，生成一个FastAPI端点代码片段。""" # 这里可以连接一个代码模板引擎，或者调用一个代码生成LLM code_template = """ from fastapi import APIRouter, Depends from pydantic import BaseModel router = APIRouter() class RequestModel(BaseModel): {request_fields} class ResponseModel(BaseModel): {response_fields} @router.{method}("/{endpoint}", response_model=ResponseModel) async def {endpoint_name}(request: RequestModel): # TODO: 实现业务逻辑 return ResponseModel(...) """ # ... 填充模板并返回代码 return generated_code

当BE Agent认领了“设计认证API”任务后，它就可以自主调用这个工具，生成/login和/register端点的代码框架，并将生成的代码提交到“共享工作区”（比如一个模拟的Git仓库）。

6. 常见问题、调试技巧与性能优化

在实际使用Tianji或自建多智能体系统时，你会遇到一系列挑战。以下是一些常见问题和我踩过的坑。

6.1 智能体“失控”或“跑题”

现象：Agent不按你设定的角色行动，开始胡言乱语，或者陷入无意义的循环对话。根因：

角色指令（System Prompt）不够清晰或约束力不足。LLM很容易“忘记”指令。
上下文过长或包含干扰信息，导致关键指令被淹没。
工具定义或返回结果格式混乱，让LLM无法正确解析。

解决方案：

强化角色指令：在指令开头使用强有力的声明，如“你必须严格遵守以下角色设定：...”。在对话过程中，可以定期在用户消息中温和地重申角色（例如，“记住，你是客服专员，你的目标是...”）。
实现“指令刷新”机制：每经过若干轮交互，或在关键节点，将原始角色指令重新插入到上下文的最前面。
精简上下文：使用对话摘要，只保留核心信息。对于工具返回的结果，可以先让一个“解析器”Agent或函数提取关键信息，再交给主Agent处理。
严格工具I/O规范：为工具定义严格的输入输出JSON Schema，并在调用前后进行格式校验。

6.2 通信死锁与循环依赖

现象：Agent A在等待Agent B的消息，Agent B也在等待Agent A的消息，或者多个Agent互相推诿任务，导致流程卡住。根因：工作流或社交协议设计存在逻辑缺陷，缺乏超时或仲裁机制。

解决方案：

设计超时机制：为每个等待消息的状态设置超时。超时后，触发备用逻辑（如向上级汇报、跳过该步骤）。
引入监督者Agent：创建一个拥有全局视角的“管理者”或“协调者”Agent。它的职责就是监控整个系统的状态，在检测到死锁时进行干预，例如直接指派任务或打破循环。
优化任务分解：确保分解后的子任务粒度合适，且责任明确，避免产生“需要对方先完成，我才能开始”的强耦合。
使用事件驱动而非纯顺序驱动：不要硬编码A->B->C的线性流程。让Agent订阅它们关心的事件（如“任务X已创建”、“API Y已就绪”）。当事件发布时，感兴趣的Agent再自主行动。这能减少不必要的等待。

6.3 成本与性能瓶颈

现象：随着Agent数量增加，API调用费用飙升，响应速度变慢。根因：每个Agent的每次“思考”（调用LLM）都产生费用和延迟。无节制的广播消息和冗长的上下文是主要开销。

优化策略：

本地模型优先：对于实验和内部应用，优先考虑在本地部署中等参数规模（7B-14B）的开源模型。虽然单次响应质量可能略逊于GPT-4，但零边际成本允许你进行大量实验和长程模拟。
消息过滤与聚合：不要所有消息都广播。设计精准的点对点或组播通信。对于状态更新，可以定期聚合后再广播。
异步与非阻塞执行：不要让整个系统同步等待一个慢速Agent。使用异步框架，让Agent在“思考”时释放资源，其他Agent可以继续运行。
缓存LLM响应：对于常见的、确定性的查询（如“根据规范生成XX代码模板”），可以建立缓存，避免重复计算。
分层智能：并非所有决策都需要大模型。一些简单的、规则明确的决策（如“消息该路由给谁”），完全可以用传统的规则引擎或小模型来处理，只在需要复杂推理时才调用大模型。

6.4 评估与调试困难

现象：系统运行了，但结果好坏难以量化，出问题时也不知道是哪个环节出了问题。解决方案：

全面日志记录：记录每一个Agent的每一次输入（收到的消息、记忆）、输出（发送的消息、调用的工具）和内部状态。这是调试的黄金标准。
可视化追踪：如果Tianji框架本身不提供，可以自己构建一个简单的可视化界面，用流程图或时间线的方式展示消息在Agent间的流动，一眼就能看出卡在哪里。
定义评估指标：根据你的场景定义成功标准。是任务完成度？是最终产物的质量（可用代码行数、测试通过率）？还是协作效率（总对话轮次、耗时）？有了指标，才能迭代优化。
“熔断”测试：创建一些极端的测试用例，例如输入混乱的需求、模拟某个Agent“罢工”，观察系统的容错和恢复能力。

多智能体系统开发目前仍处于“手工艺”阶段，充满了挑战，但也正是其魅力所在。每一次调试和优化，都让你对“协作”、“沟通”和“智能”本身有更深的理解。Tianji这样的框架降低了入门门槛，但构建一个真正高效、稳定的智能体社会，依然需要精心的设计、反复的调试和大量的实践。