企业官网建设流程全解析

1. 项目概述：从单点智能到群体进化的探索

最近在AI圈里，一个词被反复提及：AI Agent。它不再是那个只能被动回答问题的聊天机器人，而是被赋予了目标、记忆和工具使用能力的“智能体”。但单个Agent的能力终究有限，就像一个人再能干，也无法同时处理十几种不同的复杂任务。于是，一个更疯狂的想法出现了：如果让多个AI Agent协同工作，甚至让它们像生物种群一样，在协作与竞争中“自我进化”，会怎样？

这个项目，就是基于OpenClaw框架，搭建一个由11个不同职能的AI Agent组成的“数字团队”。我们的目标不是让它们各自为战，而是构建一个能够自我管理、任务流转、并从失败中学习优化策略的生态系统。OpenClaw，作为一个新兴的、强调基础设施层（Harness）与核心推理逻辑分离的AI Agent开发框架，为我们实现这个构想提供了绝佳的舞台。它不像一些“大而全”的框架试图包办一切，而是专注于提供稳定、可观测的“跑道”，让Agent的“大脑”（LLM）能更自由地发挥。

简单来说，这11个Agent就像一个小型公司的不同部门：有负责拆解和规划任务的“项目经理”，有擅长信息检索和整理的“研究员”，有专精代码编写的“工程师”，也有负责质量审查和总结的“审计员”。最初，它们只是按照预设的指令和工具笨拙地协作。但通过我们设计的进化机制——包括任务完成度的评估、工具使用效率的复盘、以及策略的遗传与变异——这些Agent在运行中开始展现出令人惊讶的适应性。它们会逐渐找到更优的任务分配路径，淘汰低效的沟通方式，甚至发明出我们未曾预设的协作技巧。这不仅仅是自动化，这是一场关于群体智能如何从简单规则中涌现的实践。

2. 核心架构设计：理解OpenClaw与多Agent系统的融合

要构建一个能进化的多Agent系统，首要任务是厘清技术栈的层级关系，并做出合理的选型。这直接决定了系统的稳定性、可扩展性和进化潜力。

2.1 技术栈选型与核心理念

为什么选择OpenClaw？在评估了LangChain、AutoGen、CrewAI等框架后，OpenClaw的“Harness”理念吸引了我们。你可以把Harness理解为航天器的发射架或赛车的底盘。它不负责制造引擎（LLM），也不决定赛车手的驾驶策略（Agent的核心逻辑），但它确保引擎能稳定输出动力，并将驾驶员的指令精准传递到每一个轮胎，同时全程监控车辆状态。

• 核心优势一：关注点分离。OpenClaw明确将基础设施（Harness）与业务逻辑（Agent）解耦。Harness负责枯燥但至关重要的部分：与大模型的稳定通信（包括重试、降级、流式响应）、工具（Tool）的注册与调用、记忆（Memory）的存储与检索、以及整个工作流的可观测性（日志、追踪）。这让开发者能更专注于设计Agent的“思考过程”和“协作策略”，而不是反复调试网络请求超时。
• 核心优势二：良好的可观测性。进化需要数据。OpenClaw内置的观测能力，让我们能清晰地看到每个Agent的思考链（Chain of Thought）、每次工具调用的输入输出、以及任务在Agent间流转的完整轨迹。这些数据是评估Agent表现、发现瓶颈、进而驱动进化的“燃料”。
• 核心优势三：语言无关性与灵活性。虽然社区示例多用Python，但OpenClaw的Harness设计理念使其能够对接不同语言实现的Agent核心。这对于我们规划中需要不同特化能力的Agent（例如，某些计算密集型任务用C++模块）来说，留有空间。

基于OpenClaw，我们确定了基础技术栈：OpenClaw Harness作为基础设施层 + Ollama本地运行大模型（如Llama 3、Qwen2.5）作为“大脑” + Docker容器化部署以隔离环境并保证一致性。

2.2 多Agent系统架构设计

11个Agent不是胡乱添加的，它们的职能划分遵循高内聚、低耦合的原则，并模拟了一个完整的任务处理流水线。整个架构分为四层：

1. 协调层（1个Agent）：任务调度者（Coordinator）。它是系统的入口和总控。负责接收外部复杂任务，进行初步理解和分解，根据任务类型和当前系统负载，将子任务派发给下游的“专业团队”。它维护着一个所有Agent的技能（Skill）与状态目录。

2. 执行层（8个Agent）：这是完成具体工作的中坚力量，分为几个小组：

   • 信息处理组：包含网络检索员（Web Researcher）和文档分析员（Doc Analyst）。前者专精使用搜索引擎API和爬虫工具获取最新信息；后者擅长读取、总结和分析上传的PDF、Word等文档。
   • 内容生成组：包含文案写手（Copywriter）和代码工程师（Code Engineer）。一个负责撰写邮件、报告、创意文案；另一个则专攻代码生成、调试和解释。
   • 逻辑与规划组：包含策略分析师（Strategist）和流程检查员（Workflow Checker）。分析师负责为复杂问题制定分步解决方案；检查员则像QA一样，验证任务执行流程是否符合逻辑，有无遗漏步骤。
   • 创意与抽象组：包含创意生成员（Creative Generator）和知识提炼员（Knowledge Refiner）。前者负责头脑风暴、提供创意点子；后者负责从对话和结果中提炼结构化知识，存入长期记忆。

3. 评审与优化层（1个Agent）：质量审计员（Quality Auditor）。它不直接生产内容，而是对执行层产出的结果进行多维度评估（相关性、准确性、完整性、格式等），给出评分和改进建议。它的评价是进化算法中“适应度”的核心输入。

4. 进化层（1个Agent）：进化引擎（Evolution Engine）。这是系统的“超脑”。它定期（如每处理100个任务后）运行，收集所有Agent的交互日志、审计员的评分以及任务最终结果。通过一套进化算法（如遗传算法或强化学习策略梯度），来调整Agent的协作策略（例如，在遇到某类任务时，Coordinator优先调用A和B的组合）、甚至优化单个Agent的提示词（Prompt）参数。

所有Agent都通过OpenClaw Harness注册，它们的工具（Tools）和记忆（Memory）由Harness统一管理。Agent间的通信采用基于消息队列（如Redis）的异步事件驱动模式，避免阻塞，并方便记录所有交互。

注意：在初期，进化引擎的逻辑可以设计得相对简单，例如，只调整任务路由的概率权重。不要一开始就追求复杂的神经网络训练，稳定性优先。复杂的进化逻辑可以放在后期迭代。

3. 环境部署与OpenClaw实战配置

一个稳定的环境是实验的基础。我们选择Docker-Compose进行一站式部署，确保从模型服务到应用框架的完全隔离和可复现。

3.1 基于Docker-Compose的一站式环境搭建

我们准备一个docker-compose.yml文件来定义三个核心服务：Ollama（用于运行本地大模型）、Redis（用于Agent间通信和缓存）、以及OpenClaw应用本身。

version: '3.8' services: ollama: image: ollama/ollama:latest container_name: openclaw-ollama ports: - "11434:11434" volumes: - ./ollama_data:/root/.ollama restart: unless-stopped networks: - agent-net redis: image: redis:7-alpine container_name: openclaw-redis ports: - "6379:6379" volumes: - ./redis_data:/data command: redis-server --appendonly yes restart: unless-stopped networks: - agent-net openclaw-app: build: ./app container_name: openclaw-multi-agent ports: - "8000:8000" volumes: - ./app:/app - ./logs:/app/logs environment: - OLLAMA_BASE_URL=http://ollama:11434 - REDIS_URL=redis://redis:6379/0 - DEFAULT_MODEL=llama3.1:8b depends_on: - ollama - redis restart: unless-stopped networks: - agent-net networks: agent-net: driver: bridge

关键配置解析：

• ollama服务：将内部端口11434映射到宿主机的11434，方便我们通过ollama run命令在宿主机上拉取和管理模型。数据卷挂载确保模型文件持久化。
• redis服务：启用AOF持久化，防止消息丢失。它作为Agent系统的“中枢神经”，传递所有任务和消息。
• openclaw-app服务：这是我们自定义的应用容器。它依赖于上面两个服务。环境变量OLLAMA_BASE_URL至关重要，它告诉OpenClaw Harness去哪里找LLM服务。这里用的是Docker内部网络的主机名ollama和端口11434。

./app目录下需要放置我们的应用代码和Dockerfile。一个简单的Dockerfile如下：

FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "main.py"]

3.2 OpenClaw Harness的初始化与模型配置

在应用代码中，我们需要初始化OpenClaw Harness，并配置好与大模型的连接。这是所有Agent能“思考”的前提。

# harness_setup.py import os from openclaw.harness import Harness from openclaw.llm_adapters import OllamaAdapter # 1. 初始化Harness harness = Harness( project_name="multi_agent_evolution", redis_url=os.getenv("REDIS_URL", "redis://localhost:6379/0") ) # 2. 配置LLM适配器 - 连接到Ollama服务 ollama_base_url = os.getenv("OLLAMA_BASE_URL", "http://localhost:11434") default_model = os.getenv("DEFAULT_MODEL", "llama3.1:8b") llm_adapter = OllamaAdapter( base_url=ollama_base_url, model=default_model, temperature=0.7, # 控制创造性，可根据Agent角色调整 request_timeout=120 # 对于复杂任务，设置较长超时 ) # 3. 将LLM适配器注册到Harness harness.register_llm_adapter("primary_llm", llm_adapter) # 4. 定义一个公共工具示例：计算器 @harness.tool(name="calculator", description="Perform basic arithmetic calculations.") def calculator(expression: str) -> str: """计算数学表达式，如 '2 + 3 * 4'。""" try: # 警告：在生产环境中使用eval有安全风险，此处仅为演示。 # 应替换为安全的表达式求值库（如 ast.literal_eval 配合简单解析器）。 result = eval(expression, {"__builtins__": {}}, {}) return f"The result of '{expression}' is {result}." except Exception as e: return f"Calculation error: {e}" print("OpenClaw Harness 初始化完成，LLM和基础工具已注册。")

关键点与避坑指南：

1. Ollama连接问题：最常见的错误是OLLAMA_BASE_URL配置不正确。在Docker内，必须使用服务名（如http://ollama:11434）；在本地调试，则是http://localhost:11434。务必通过curl http://ollama:11434/api/tags测试连接。
2. 模型加载：确保在Ollama容器中已经拉取了对应的模型（如docker exec openclaw-ollama ollama pull llama3.1:8b）。模型名必须完全匹配。
3. 工具安全：上面的calculator工具使用了eval，这在生产环境是极度危险的，因为它可能执行任意代码。实际开发中，必须使用安全的库（如ast.literal_eval配合一个简单的数学表达式解析器）或严格限制输入。
4. 超时设置：根据任务复杂度调整request_timeout。对于需要长文本生成或复杂推理的Agent，可能需要增加这个值，避免任务中途失败。

4. 构建11个AI Agent：定义角色、技能与协作方式

有了稳定的Harness，我们就可以开始“创造”生命了。每个Agent本质上是一个具有特定系统提示词（System Prompt）和一套专属工具（Tools）的配置。

4.1 核心Agent：任务调度者（Coordinator）的实现

Coordinator是大脑中的前额叶，负责决策和分配。它的提示词需要精心设计，以理解全局并做出合理调度。

# agents/coordinator.py from openclaw.agents import BaseAgent from .shared_memory import shared_task_queue # 假设一个共享任务队列 class CoordinatorAgent(BaseAgent): name = "Coordinator" role = "项目总调度与任务分解专家" # 系统提示词是Agent的“人格”和“职责说明书” system_prompt = """ 你是多AI智能体系统的总调度员（Coordinator）。你的核心职责是接收复杂的外部任务，并将其高效、合理地分解和分配给最合适的专业Agent执行。 你拥有所有Agent的技能目录。请遵循以下步骤工作： 1. **理解任务**：仔细分析用户请求，明确最终目标、约束条件和隐含需求。 2. **任务分解**：将复杂任务拆解成一系列顺序或并行的、原子化的子任务。每个子任务应尽可能清晰地描述，并注明期望的输出格式。 3. **Agent匹配**：根据子任务类型，从技能目录中选择最匹配的一个或多个Agent来负责。考虑Agent的当前负载（如有）。 4. **发布指令**：将子任务以结构化消息的形式发布到任务队列，指定执行Agent和优先级。 5. **监控与汇总**：跟踪子任务完成状态，收集结果，并在所有子任务完成后，整合成最终答复给用户。 技能目录： - Web Researcher: 擅长实时信息搜索与摘要。 - Doc Analyst: 擅长分析上传的文档（PDF, TXT, DOCX）并提取关键信息。 - Strategist: 擅长为复杂问题制定分步解决方案和策略规划。 - Code Engineer: 擅长编写、解释、调试代码。 - Copywriter: 擅长撰写各类文案、报告、邮件。 - Workflow Checker: 擅长检查流程逻辑的完整性与合理性。 - Creative Generator: 擅长头脑风暴，提供创意点子。 - Knowledge Refiner: 擅长从文本中提炼结构化知识。 - Quality Auditor: 擅长评估内容质量。 当前请开始处理用户任务。 """ def __init__(self, harness, llm_adapter_name="primary_llm"): super().__init__(harness, llm_adapter_name) # Coordinator可能需要访问共享状态，如任务队列 self.task_queue = shared_task_queue async def process_task(self, user_input: str): """处理用户输入的主要方法""" # 1. 让LLM根据提示词进行思考，生成任务分解计划 planning_response = await self.harness.generate( agent=self, messages=[{"role": "user", "content": user_input}], stream=False ) # 这里假设LLM的返回是结构化的（如JSON），实际需要做解析 # 解析 planning_response，得到子任务列表和分配方案... # 2. 将子任务推送到队列 for subtask in subtask_list: self.task_queue.put({ "task_id": generate_id(), "description": subtask["desc"], "assigned_agent": subtask["agent"], "meta": subtask.get("meta", {}) }) return {"status": "tasks_dispatched", "plan": planning_response}

4.2 专业Agent范例：代码工程师（Code Engineer）与质量审计员（Quality Auditor）

让我们再看两个风格迥异的Agent实现。

Code Engineer需要具体的工具，比如调用代码解释器、访问API文档库。

# agents/code_engineer.py class CodeEngineerAgent(BaseAgent): name = "Code Engineer" role = "软件代码生成与审查专家" system_prompt = """ 你是一名资深软件工程师。你擅长根据需求编写清晰、高效、可维护的代码，也擅长审查和解释现有代码。 你的输出必须是可直接运行的代码片段，或详细的代码审查意见。对于不明确的请求，你会主动询问以澄清需求。 你精通Python、JavaScript等多种语言。 """ def __init__(self, harness, llm_adapter_name="primary_llm"): super().__init__(harness, llm_adapter_name) # 注册专属工具 self.register_tool(self._search_api_doc) self.register_tool(self._run_unit_test) # 假设有简单测试工具 @harness.tool(name="search_api_doc", description="Search the internal API documentation for a given topic.") def _search_api_doc(self, query: str) -> str: # 模拟或实际连接内部知识库 return f"Search results for '{query}': ..." # 主要的任务处理方法 async def write_code(self, requirement: str): # 使用工具和LLM生成代码 context = await self._search_api_doc(requirement) messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": f"需求：{requirement}\n相关API信息：{context}\n请生成代码。"} ] response = await self.harness.generate(agent=self, messages=messages) return response

Quality Auditor是进化系统的“裁判”，它的评估标准需要量化。

# agents/quality_auditor.py class QualityAuditorAgent(BaseAgent): name = "Quality Auditor" role = "内容质量多维评估专家" system_prompt = """ 你是一个严格的质量审计员。你需要从多个维度对给定内容进行评估打分（1-10分），并提供具体的改进建议。 评估维度包括： 1. **准确性**：信息/事实是否准确无误。 2. **相关性**：内容是否紧密围绕任务要求。 3. **完整性**：是否全面覆盖了任务的所有要点。 4. **清晰度**：表达是否清晰、逻辑是否通顺。 5. **实用性**：结果是否可直接使用或易于实施。 你的输出必须是严格的JSON格式： { "scores": {"accuracy": x, "relevance": x, "completeness": x, "clarity": x, "practicality": x}, "overall_score": x.x, "strengths": ["..."], "weaknesses": ["..."], "suggestions": ["..."] } """ async def audit(self, task_description: str, agent_output: str) -> dict: messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": f"原始任务：{task_description}\n待评估输出：{agent_output}"} ] response = await self.harness.generate(agent=self, messages=messages) # 解析JSON响应 try: audit_result = json.loads(response) return audit_result except json.JSONDecodeError: # 如果LLM没有返回标准JSON，则降级处理 return {"error": "Failed to parse audit result", "raw_response": response}

4.3 Agent间的通信与任务流设计

Agent不能是孤岛。我们采用基于Redis Pub/Sub的异步消息传递。

# communication/broker.py import redis.asyncio as redis import json class MessageBroker: def __init__(self, redis_url): self.redis_client = redis.from_url(redis_url) self.pubsub = self.redis_client.pubsub() async def publish_task(self, channel: str, task: dict): """向指定频道（通常是某个Agent的收件箱）发布任务""" await self.redis_client.publish(channel, json.dumps(task)) async def subscribe(self, channel: str, callback): """订阅频道，收到消息后调用回调函数处理""" await self.pubsub.subscribe(channel) async for message in self.pubsub.listen(): if message['type'] == 'message': data = json.loads(message['data']) await callback(data) # 在Coordinator中分配任务 broker = MessageBroker(REDIS_URL) await broker.publish_task(channel="agent_code_engineer_inbox", task={ "id": "task_123", "from": "Coordinator", "type": "code_generation", "instruction": "编写一个Python函数，计算斐波那契数列的第n项。", "context": {...} }) # 在Code Engineer Agent中启动时订阅自己的收件箱 async def code_engineer_message_handler(task): if task['type'] == 'code_generation': result = await self.write_code(task['instruction']) # 完成后，将结果发布到“任务完成”频道或直接通知Coordinator await broker.publish_task(channel="task_results", task={"task_id": task['id'], "result": result}) await broker.subscribe("agent_code_engineer_inbox", code_engineer_message_handler)

这种设计实现了松耦合的异步通信，每个Agent只关心自己的收件箱和要发布的结果频道，大大提升了系统的并发能力和可扩展性。

5. 实现“自我进化”机制：从静态协作到动态优化

这是项目最激动人心的部分。进化机制让系统从“自动执行”变为“自主优化”。我们设计了一个相对简单但有效的基于策略权重调整的进化算法。

5.1 进化引擎的设计与数据收集

进化引擎（Evolution Engine）是一个特殊的Agent，它不处理常规任务，而是定期分析系统运行数据。

# agents/evolution_engine.py import numpy as np from collections import defaultdict import json class EvolutionEngine: def __init__(self, harness, audit_agent, coordinator_agent): self.harness = harness self.auditor = audit_agent self.coordinator = coordinator_agent # 策略库：记录针对不同任务类型，调用不同Agent组合的历史成功率 self.strategy_db = defaultdict(lambda: defaultdict(lambda: {'success': 0, 'total': 0})) # 从文件或数据库加载历史策略 self.load_strategies() def load_strategies(self): try: with open('strategy_db.json', 'r') as f: data = json.load(f) # 将嵌套的dict恢复为defaultdict for task_type, agents in data.items(): for agent, stats in agents.items(): self.strategy_db[task_type][agent] = stats except FileNotFoundError: print("策略数据库不存在，将从头开始构建。") def save_strategies(self): # 将defaultdict转换为普通dict以便序列化 save_data = {k: dict(v) for k, v in self.strategy_db.items()} with open('strategy_db.json', 'w') as f: json.dump(save_data, f, indent=2) async def analyze_and_evolve(self, recent_tasks: list): """分析近期任务数据，并进化策略""" print("进化引擎开始本轮分析...") for task in recent_tasks: task_type = task['type'] agent_used = task['assigned_agent'] audit_score = task.get('audit_score', 0) # 来自Quality Auditor的评分 # 更新策略数据库：如果评分高于阈值（如7分），视为成功 is_success = audit_score >= 7.0 self.strategy_db[task_type][agent_used]['total'] += 1 if is_success: self.strategy_db[task_type][agent_used]['success'] += 1 # 进化算法核心：调整Coordinator的分配策略 for task_type, agent_stats in self.strategy_db.items(): success_rates = {} for agent, stats in agent_stats.items(): if stats['total'] > 0: success_rates[agent] = stats['success'] / stats['total'] else: success_rates[agent] = 0.0 # 选择成功率最高的前N个Agent作为该任务类型的推荐组合 recommended_agents = sorted(success_rates.items(), key=lambda x: x[1], reverse=True)[:3] print(f"任务类型 '{task_type}' 的推荐Agent更新为: {recommended_agents}") # 将推荐策略传递给Coordinator Agent，更新其内部的“技能目录”权重 await self.update_coordinator_strategy(task_type, [agent for agent, _ in recommended_agents]) self.save_strategies() print("本轮进化完成。") async def update_coordinator_strategy(self, task_type: str, recommended_agents: list): """通知Coordinator更新其内部决策逻辑""" # 这里可以通过消息队列发送策略更新指令，或直接调用Coordinator的方法 update_message = { "event": "strategy_update", "task_type": task_type, "priority_agents": recommended_agents } # 假设Coordinator订阅了'evolution_updates'频道 await self.broker.publish_task('evolution_updates', update_message)

5.2 进化循环的触发与策略迭代

进化不是连续的，而是周期性的。我们在主循环中设置一个计数器。

# main_loop.py TASKS_BETWEEN_EVOLUTION = 100 # 每处理100个任务，触发一次进化分析 task_counter = 0 recent_task_log = [] # 用于存储近期任务日志，包含任务类型、执行Agent、审计评分等 async def main_loop(): global task_counter, recent_task_log evolution_engine = EvolutionEngine(...) coordinator = CoordinatorAgent(...) # ... 初始化其他Agent和消息broker while True: # 1. 从外部（如API）获取新任务 new_task = await fetch_external_task() if not new_task: await asyncio.sleep(1) continue # 2. Coordinator处理并分配任务 dispatch_result = await coordinator.process_task(new_task) # 3. 模拟任务执行与结果收集（实际中由各个Agent异步完成） final_result, audit_report = await simulate_agent_workflow(dispatch_result) # 4. 记录任务日志，用于进化分析 task_log_entry = { "id": new_task.id, "type": classify_task_type(new_task), "assigned_agent": dispatch_result['primary_agent'], "audit_score": audit_report.get('overall_score', 0), "timestamp": datetime.now() } recent_task_log.append(task_log_entry) # 5. 检查是否触发进化 task_counter += 1 if task_counter >= TASKS_BETWEEN_EVOLUTION: print(f"已处理 {task_counter} 个任务，启动进化分析...") await evolution_engine.analyze_and_evolve(recent_task_log) # 重置计数器和日志 task_counter = 0 recent_task_log.clear()

通过这个循环，系统每完成一定数量的任务，就会自动回顾历史表现，找出哪些Agent在哪些任务上表现更好，并动态调整未来的任务分配策略。这就是“自我进化”的雏形：系统性能随着经验积累而提升。

6. 实战演练与效果观察：一个完整任务的生命周期

让我们跟踪一个具体任务——“为我制定一个本周的个人学习计划，主题是‘机器学习模型部署’”，看看这11个Agent如何协作并可能进化。

1. 任务接收与分解（Coordinator）：Coordinator分析请求，识别出任务类型为“计划制定”，涉及“信息检索”和“内容编排”。它将其分解为：

   • 子任务A（信息检索）：查找“机器学习模型部署”的最新工具、最佳实践和常见陷阱。 -> 分配给Web Researcher。
   • 子任务B（知识提炼）：从检索结果中提炼核心知识点和技能树。 -> 分配给Knowledge Refiner。
   • 子任务C（计划制定）：基于提炼的知识，制定一份为期7天、每天1-2小时的可执行学习计划。 -> 分配给Strategist。
   • 子任务D（格式优化）：将计划润色成清晰、鼓舞人心的文本。 -> 分配给Copywriter。

2. 并行执行与流转：

   • Web Researcher 调用搜索工具，返回几篇最新的博客文章和官方文档链接。
   • Knowledge Refiner 接收这些链接和摘要，输出一个结构化的知识图谱，包括“Docker容器化”、“API服务框架（FastAPI/Flask）”、“云平台选择（对比）”等节点。
   • Strategist 接收知识图谱，制定计划：“Day1: 学习Docker基础；Day2: 将简单模型打包为Docker镜像；Day3: 学习FastAPI基础...”。
   • Copywriter 将计划表转化为一段优美的激励性文字。

3. 质量审计（Quality Auditor）：审计员收到最终的学习计划文档。它从准确性（技术点是否正确）、完整性（是否覆盖部署全流程）、实用性（时间安排是否合理）等维度打分。假设这次打了8.5分，并建议“增加关于模型监控（如Prometheus）的入门内容”。

4. 进化记录：本次任务被记录为类型“计划制定”，主要执行Agent为“Strategist”和“Copywriter”，得分8.5。成功计数器累加。

5. 进化触发：当类似任务（“制定XX学习计划”）多次成功由Strategist和Copywriter组合完成，且得分较高时，进化引擎会强化这种关联。未来Coordinator遇到“计划制定”类任务时，会更高概率地直接启用这个成功组合，甚至跳过Web Researcher和Knowledge Refiner（如果知识库已足够），从而缩短任务路径，提高效率。

我们观察到，经过几百个任务的训练，系统在处理“代码调试”类任务时，从最初的总是先派给Code Engineer，逐渐进化出“先由Workflow Checker进行逻辑预检，再交给Code Engineer修改”的更优路径，因为预检能提前发现一些逻辑矛盾，减少了Code Engineer的无效工作。这就是简单的策略进化带来的群体智能提升。

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

在实际搭建和运行过程中，你一定会遇到各种问题。以下是一些典型问题及解决方案。

7.1 OpenClaw与Ollama连接故障排查

这是最常遇到的问题，表现为Agent无法生成回复或报连接错误。

• 症状：openclaw.llm_adapters.OllamaAdapterError: Failed to connect to Ollama server at http://ollama:11434.
• 排查步骤：
  1. 检查Ollama容器状态：docker ps | grep ollama。确保状态为Up。
  2. 进入容器测试：docker exec openclaw-ollama curl -s http://localhost:11434/api/tags。如果返回模型列表，说明Ollama内部服务正常。
  3. 检查网络互通：在OpenClaw应用容器内执行ping ollama和curl http://ollama:11434/api/tags。如果不通，检查Docker Compose网络配置，确保所有服务在同一个自定义网络（如agent-net）下。
  4. 检查环境变量：确认OpenClaw应用容器的OLLAMA_BASE_URL环境变量是否正确设置为http://ollama:11434（在Docker网络内）。
  5. 模型是否存在：确保所需模型已在Ollama容器内拉取：docker exec openclaw-ollama ollama list。

7.2 Agent响应慢或超时处理

多Agent系统涉及多次LLM调用和网络通信，延迟是常态。

• 优化策略：
  1. 设置合理超时：在初始化OllamaAdapter时，根据任务复杂度设置request_timeout（如30-120秒）。对于Coordinator的复杂规划任务，可以设置更长。
  2. 启用流式响应：对于需要长时间生成的内容，使用Harness的流式响应（stream=True），可以让用户先看到部分结果，提升体验。
  3. 异步并发：确保Agent间的通信和任务处理是异步的（使用asyncio）。不要让一个Agent的慢操作阻塞整个事件循环。
  4. LLM参数调优：适当降低temperature（如从0.8降到0.3）可以减少生成内容的随机性，有时能加快“思考”速度。对于创造性任务（Creative Generator）可以调高，对于逻辑性任务（Workflow Checker）可以调低。
  5. 缓存机制：在Harness层或自己实现一个简单的缓存，对于相同或相似的查询（例如，多次询问同一概念的定义），直接返回缓存结果，避免重复调用LLM。

7.3 进化效果不显著或策略震荡

进化引擎没有带来明显提升，或者策略频繁在几个选项间摇摆。

• 可能原因与对策：
  1. 数据量不足：进化需要足够的样本。TASKS_BETWEEN_EVOLUTION参数不宜过小，初期可以设置为200或500，确保统计显著性。
  2. 评估标准（适应度函数）单一：仅靠Quality Auditor的总体评分可能不够精细。可以引入更多维度，如任务完成耗时、调用工具次数（越少可能效率越高）、用户反馈（如果有）等，综合计算适应度。
  3. 探索与利用的平衡：如果总是选择历史成功率最高的Agent，系统会陷入局部最优，无法尝试新的、可能更好的组合。可以在进化算法中引入“探索率”（ε-greedy策略），比如有10%的概率随机分配一个不同的Agent来尝试。
  4. 任务分类过于粗糙：“计划制定”是一个大类，其中“技术学习计划”和“旅行计划”的最佳Agent组合可能不同。需要让Coordinator或进化引擎进行更细粒度的任务分类。

7.4 系统监控与日志管理

当11个Agent同时运行时，没有良好的监控，问题将难以定位。

• 必备监控点：
  1. Harness内置日志：启用OpenClaw的详细日志，记录每一次LLM调用、工具调用的输入输出和耗时。
  2. 消息队列堆积：监控Redis中各个Agent收件箱的消息数量，如果某个Agent的队列持续增长，说明它可能成为了瓶颈。
  3. Agent健康状态：为每个Agent实现一个简单的“心跳”机制，定期报告自身状态（空闲、忙碌、错误）。
  4. 进化指标可视化：将strategy_db.json中的数据定期导出，用简单图表（如折线图）展示不同任务类型下各Agent成功率的趋势变化，直观看到进化效果。

实操心得：在项目初期，不要追求完美的进化算法。先用最简单的规则（如成功率加权随机选择）跑起来，收集数据。很多时候，问题不是出在进化逻辑上，而是出在任务分解的合理性、Agent提示词的质量、或评估标准的不准确上。先让系统稳定地跑起来，再考虑让它跑得更快更好。另外，为每一个关键操作（如任务分配、结果评估）都加上唯一ID并贯穿日志，这样在排查一个具体任务的失败原因时，你可以像看故事线一样追溯它在所有Agent间的流转全过程。