AI智能体编排框架实战：构建具备记忆与协作能力的智能系统

1. 项目概述当AI智能体需要“记忆”与“协作”在AI智能体开发领域我们常常面临一个核心挑战如何让智能体不仅能在单次对话中表现出色还能记住历史、规划未来并与其他智能体协同工作这就像组建一支足球队每个球员智能体技术再好如果没有统一的战术记忆历史上下文、清晰的跑位规划任务分解和默契的传球配合智能体间协作也难以赢得比赛。AlekseiUL/agentforge-openclaw这个开源项目正是为了解决这类问题而生的一个“智能体编排与记忆框架”。简单来说agentforge-openclaw是一个为构建复杂、可记忆、可协作的AI智能体系统而设计的工具包。它不是一个单一的“超级智能体”而是一个“智能体工厂”和“指挥中心”。它的核心价值在于为开发者提供了一套标准化的“乐高积木”让你能轻松地将多个具有不同能力的AI模型如GPT、Claude等组装起来赋予它们持久的记忆能力和彼此沟通的管道从而完成那些单个模型难以处理的、需要多步骤推理和长期上下文维护的复杂任务。想象一下你要开发一个“个人研究助理”智能体。它需要能理解你的长期研究兴趣记忆根据一篇新论文自动分解出“总结摘要”、“批判性分析”、“查找相关文献”等子任务规划并可能调用不同的专业模型或工具去执行这些子任务动作执行最后将结果整合并更新你的知识库记忆回写。agentforge-openclaw就是帮你搭建这个系统的脚手架。它适合谁呢如果你是一名AI应用开发者、研究者或者对构建超越简单问答的下一代AI应用感兴趣正在苦恼于如何管理智能体的状态、工具调用链和跨会话记忆那么这个项目值得你深入探索。接下来我将带你拆解它的核心设计、手把手实现一个基础智能体并分享在实际集成中会遇到的那些“坑”和应对技巧。2. 核心架构与设计哲学拆解要理解agentforge-openclaw不能只看代码得先理解其背后的设计哲学。它的名字“OpenClaw”颇有深意“Claw”意为爪子、抓手暗示其旨在为智能体提供抓取、操作信息和任务的能力而“Open”则点明了其开源与模块化特性。整个框架的设计围绕着几个关键概念展开我们可以将其类比为一个现代化的“特工指挥部”。2.1 核心组件指挥部里的关键角色框架的核心由几个主要组件构成它们各司其职共同协作智能体Agent这是执行任务的基本单元。你可以把它理解为指挥部派出的“特工”。每个特工都有特定的技能由背后的LLM模型和提示词定义比如有的擅长信息检索SearchAgent有的擅长代码编写CodeAgent。在agentforge中智能体是可配置的你可以定义它的角色、目标以及可供使用的工具。工具Tools这是智能体的“装备”。一个特工光有脑子不够还需要手枪、望远镜、开锁器等工具。在框架中工具可以是任何可执行的函数或API例如网络搜索、数据库查询、文件读写、调用另一个API等。智能体根据任务需求自主选择并调用合适的工具。记忆Memory这是指挥部的“档案室”。这是agentforge区别于许多简单智能体框架的关键。记忆分为不同类型会话记忆Conversation Memory存储当前对话的上下文确保智能体不会“失忆”。长期记忆Long-term Memory通常由向量数据库如Chroma, Pinecone实现用于存储和检索智能体在过去所有交互中学到的知识、事实或用户偏好。这使得智能体能够进行跨会话的学习和个性化服务。任务队列与编排器Orchestrator这是指挥部的“调度中心”。当一个复杂任务如“写一份行业分析报告”下达时编排器负责将其分解成一系列子任务“搜集A公司信息”、“搜集B公司信息”、“对比分析”、“生成报告”并将这些子任务排入队列分发给合适的智能体去执行。它还负责监控任务状态处理失败和重试。动作空间Action Space定义了智能体在特定环境下可以采取的所有合法动作的集合。这通常与可用工具列表紧密相关帮助智能体进行合理的决策。这种组件化设计的好处是解耦和可复用。你可以像搭积木一样更换不同的LLM模型支持OpenAI、Anthropic、本地模型等接入不同的向量数据库作为记忆后端或者自定义任何你需要的工具而无需重写整个系统逻辑。2.2 工作流一个任务的生命周期让我们跟踪一个用户查询“帮我总结最近三篇关于神经网络剪枝的论文并对比它们的优劣”在框架中是如何被处理的接收与解析用户输入被主控智能体或一个专门的“路由Agent”接收。该智能体分析查询识别出这是一个需要多步骤分解和信息检索的复合任务。任务规划与分解编排器介入根据任务类型可能调用一个“规划Agent”将大任务分解为有序子任务链[“搜索并获取论文A”, “搜索并获取论文B”, “搜索并获取论文C”, “总结论文A核心方法”, “总结论文B核心方法”, “总结论文C核心方法”, “对比三篇论文的优缺点”]。智能体调度与执行编排器从任务队列中取出第一个子任务“搜索并获取论文A”根据任务性质搜索将其分配给“搜索专家Agent”。该Agent激活其LLM内核思考后决定调用“网络搜索工具”和“学术数据库API工具”。工具执行后返回论文信息和链接。记忆存储与上下文传递获取的论文信息被存储到“会话记忆”中也可能被提取关键信息存入“长期记忆”向量库。当执行到“总结论文A”任务时负责总结的Agent可以从记忆中直接检索出论文A的内容而无需重新搜索。结果整合与交付所有子任务完成后编排器或一个“总结Agent”将各个子结果三篇论文的总结和对比点整合成一份连贯的最终答案返回给用户。整个任务链的状态和结果也可能被选择性存入长期记忆供未来参考。这个流程展示了框架如何将规划Planning、记忆Memory、工具使用Tool Use和动作执行Action有机结合起来这正是构建高级智能体应用Agentic AI的核心范式。注意agentforge-openclaw提供了实现上述范式的底层机制和接口但具体的任务分解逻辑、智能体协作策略如ReAct, Plan-and-Execute需要开发者基于其框架进行实现或配置。它给了你强大的武器但战术需要你自己设计。3. 环境搭建与核心配置实战理论讲得再多不如动手搭一个。下面我将带你从零开始配置一个具备基础记忆和工具调用能力的智能体。我们以创建一个“内网知识库问答助手”为例。3.1 基础环境与依赖安装首先确保你的开发环境已安装Python建议3.9以上版本。然后克隆仓库并安装依赖。# 克隆项目仓库 git clone https://github.com/AlekseiUL/agentforge-openclaw.git cd agentforge-openclaw # 安装核心依赖 pip install -r requirements.txtrequirements.txt通常包含了openai,chromadb(用于向量记忆),langchain(可能用于工具集成) 等关键库。如果项目使用了较新的特性务必关注其README中的版本要求。接下来是最关键的一步配置API密钥和环境变量。框架通常通过.env文件或环境变量来管理敏感配置。# 复制环境变量示例文件 cp .env.example .env然后用文本编辑器打开.env文件填入你的密钥# .env 文件示例 OPENAI_API_KEYsk-your-openai-api-key-here # 如果你使用其他模型如Anthropic Claude ANTHROPIC_API_KEYyour-claude-key-here # 向量数据库配置以Chroma为例使用本地持久化模式 CHROMA_PERSIST_DIRECTORY./chroma_db这里有个实操心得对于本地开发CHROMA_PERSIST_DIRECTORY指定一个本地路径即可ChromaDB会在该目录下创建数据库文件。对于生产环境你可能需要连接远程的ChromaDB服务或使用Pinecone等云服务配置方式会有所不同请参考对应数据库的文档。3.2 核心配置文件解读agentforge的强大之处在于其高度的可配置性。核心配置通常位于config/或agents/目录下采用YAML或JSON格式。你需要重点关注以下几个配置智能体定义agent_definition.yaml# 示例定义一个总结助手智能体 SummaryAgent: llm: gpt-4-turbo # 使用的LLM模型 system_prompt: | 你是一个专业的文本总结助手。你的任务是用简洁清晰的语言总结用户提供的文本内容突出核心观点和关键结论。 总结语言为中文。 temperature: 0.2 # 创造性较低保证总结的稳定性 tools: [“fetch_from_memory] # 该智能体可以使用的工具列表在这个配置里system_prompt是灵魂它定义了智能体的“人格”和任务边界。为不同角色精心设计提示词是提升智能体表现最有效的方法。工具注册tools_registry.py 或类似文件 工具需要先在框架中注册才能被智能体调用。下面是一个自定义工具的例子# my_tools.py from agentforge.utils.tool_decorator import tool tool(namequery_internal_wiki, description从内部知识库Wiki中搜索相关信息。) def query_internal_wiki(search_query: str) - str: 根据查询词搜索内部Wiki系统并返回相关片段。 Args: search_query: 用户搜索的关键词。 Returns: 搜索到的相关文本内容。 # 这里实现实际的搜索逻辑例如调用Wiki的API或查询本地数据库 # 模拟返回 results simulate_wiki_search(search_query) return \n.join(results)然后你需要在主配置或初始化代码中将这个工具注册到框架的工具库中并分配给相应的智能体。记忆存储配置memory_config.yamlLongTermMemory: type: “chroma” # 记忆存储后端类型 collection_name: “agent_long_term_mem” # 向量数据库中的集合名 embedding_model: “text-embedding-3-small” # 用于生成嵌入向量的模型 persist_directory: “./chroma_db” # 与.env中对应这个配置决定了智能体的“长期记忆”存在哪里、如何被索引。选择合适的embedding_model对检索质量至关重要。3.3 初始化并运行你的第一个智能体配置完成后我们可以写一个简单的脚本来测试智能体。假设我们已经定义好了一个SummaryAgent。# test_agent.py import asyncio from agentforge import AgentForge async def main(): # 1. 初始化框架会自动加载.env和config配置 forge AgentForge() # 2. 获取我们定义的总结智能体 summary_agent forge.get_agent(“SummaryAgent”) # 3. 准备一段需要总结的文本 long_text “”” 这里是一篇关于神经网络剪枝的冗长论文摘要... “”” # 4. 向智能体发送任务 user_query f“请总结以下文本\n{long_text}” result await summary_agent.run(taskuser_query) # 5. 打印结果 print(“智能体总结结果”) print(result[“response”]) # 结果通常是一个字典包含response, metadata等 if __name__ “__main__”: asyncio.run(main())运行这个脚本你应该能看到智能体返回的总结内容。至此一个最基本的、具备固定能力的智能体就跑通了。但这只是开始单个智能体能力有限接下来我们要让它学会使用工具和利用记忆。4. 实现工具调用与记忆持久化让智能体“动手做事”和“记住过去”是赋予其实用价值的关键。我们接着上面的例子让SummaryAgent在总结前先尝试从知识库记忆里查找背景信息。4.1 为智能体装配并调用工具首先确保我们之前定义的query_internal_wiki工具已经正确注册。然后修改SummaryAgent的配置将其加入到工具列表中。# 更新后的 SummaryAgent 配置 SummaryAgent: llm: gpt-4-turbo system_prompt: | 你是一个专业的文本总结助手。你的任务是用简洁清晰的语言总结用户提供的文本内容。 在开始总结前你可以先使用工具查询内部知识库了解相关背景知识这有助于你做出更准确的总结。 如果用户提供的文本中提到了某些专业概念你可以先查询它们。 总结语言为中文。 temperature: 0.2 tools: [“query_internal_wiki”] # 现在它有了查询工具接下来我们需要修改智能体的运行逻辑使其能够根据情况自主决定是否调用工具。这通常涉及与智能体的“推理循环”交互。在agentforge中智能体的run方法可能会自动处理简单的工具调用但对于复杂逻辑我们可能需要更精细的控制。一个常见的模式是使用ReAct (Reasoning Acting)模式。虽然框架可能内置了支持但理解其原理很重要# 模拟ReAct循环的简化示例实际框架可能封装了此逻辑 async def run_agent_with_react(agent, initial_query): context initial_query max_steps 5 for step in range(max_steps): # 1. 让Agent思考Reasoning thought_response await agent.think(context) thought thought_response[“response”] # 解析思考内容判断是否需要行动Acting if “Action:” in thought: # 提取要调用的工具和参数 action_line ... # 解析出类似“Action: query_internal_wiki[‘神经网络剪枝’]”的内容 tool_name, tool_input parse_action(action_line) # 2. 执行工具调用Acting tool_result await agent.use_tool(tool_name, tool_input) # 3. 将观察结果Observation加入上下文进入下一轮循环 context f“{thought}\nObservation: {tool_result}\n” else: # 如果思考结果中没有Action则认为推理完成返回最终答案 final_answer thought return final_answer return “达到最大推理步数任务未完成。”在实际使用agentforge时你可能不需要手动实现这个循环框架的agent.run()可能已经集成了类似的机制。你需要做的是在system_prompt中清晰地指导智能体如何格式化和提出工具调用请求并确保工具的描述清晰准确以便智能体理解何时该调用它。4.2 集成向量数据库实现长期记忆短期会话记忆通常由框架自动管理。长期记忆则需要我们显式地存储和检索。以下是如何将智能体与ChromaDB向量记忆集成的步骤初始化记忆存储在框架初始化时长期记忆模块应该已经根据memory_config.yaml配置准备就绪。存储记忆当智能体完成一次有价值的交互或学到新知识时我们可以选择性地将其存储。async def store_memory(forge, content, metadata{}): 将一段内容存储到长期记忆。 Args: forge: AgentForge实例 content: 要存储的文本内容 metadata: 相关的元数据如来源、类型、时间戳等 memory forge.get_memory(“LongTermMemory”) # 通常需要将内容分成适当的片段chunks chunks split_text_into_chunks(content) for chunk in chunks: await memory.store(textchunk, metadatametadata) print(f“已存储 {len(chunks)} 个片段到长期记忆。”)检索记忆在智能体处理任务时可以先从记忆中检索相关背景信息。async def retrieve_memory(forge, query, top_k3): 从长期记忆中检索与查询最相关的片段。 Args: forge: AgentForge实例 query: 检索查询词 top_k: 返回最相关的K个结果 Returns: 检索到的相关文本列表 memory forge.get_memory(“LongTermMemory”) results await memory.search(queryquery, top_ktop_k) # results 通常是包含文本和相似度分数的字典列表 retrieved_texts [res[“text”] for res in results] return retrieved_texts在智能体工作流中应用记忆我们可以在调用智能体前先检索记忆并将结果作为上下文的一部分提供给智能体。async def enhanced_summary(forge, user_query, text_to_summarize): # 1. 从用户查询和待总结文本中提取关键词进行记忆检索 search_query extract_keywords(user_query text_to_summarize[:500]) background_info await retrieve_memory(forge, search_query, top_k2) # 2. 构建增强的提示词 enhanced_prompt f“”” 以下是从知识库中检索到的相关背景信息 {‘\n’.join(background_info)} 请基于以上背景信息更好地理解并总结用户提供的文本 {text_to_summarize} 用户的具体要求是{user_query} “”” # 3. 调用智能体 agent forge.get_agent(“SummaryAgent”) result await agent.run(taskenhanced_prompt) return result通过这种方式你的智能体就不再是“金鱼脑”了它能利用过去积累的知识做出更精准、更个性化的响应。这里有一个关键技巧存储记忆时metadata非常重要。为每个记忆片段打上清晰的标签如doc_type: “research_paper”,topic: “model_compression”,date: “2023-10”能极大提升后续检索的准确性和效率。5. 构建多智能体协作系统单个智能体再强大也有其能力边界。agentforge-openclaw的真正威力在于编排多个智能体协同工作。我们来设计一个简单的多智能体系统一个“需求分析Agent”、一个“研究Agent”和一个“写作Agent”共同完成“撰写技术博客初稿”的任务。5.1 设计智能体团队与协作流程需求分析Agent (AnalystAgent)职责与用户对话澄清模糊需求将用户想法转化为结构化的、可执行的任务清单。例如用户说“我想写篇关于大模型微调技巧的博客”该Agent会通过提问确定博客主题、目标读者、篇幅、重点技巧范围等并输出一个任务概要。配置使用高temperature如0.7的LLM以鼓励其提出澄清性问题。工具可能包括“查询用户偏好记忆”。研究Agent (ResearcherAgent)职责根据AnalystAgent产出的任务概要进行信息搜集和整理。它会调用网络搜索工具、内部文档检索工具收集相关资料、数据、案例并整理成结构化的研究笔记。配置需要配备强大的检索工具。system_prompt强调信息验证和来源追溯。写作Agent (WriterAgent)职责接收研究笔记和任务概要撰写结构完整、语言流畅的博客文章草稿。它需要遵循特定的风格指南。配置可以使用专门优化过写作能力的LLM。工具可能包括“语法检查工具”、“风格一致性检查工具”。协作流程可以设计为一个线性管道用户 - AnalystAgent - ResearcherAgent - WriterAgent - 用户。也可以设计成更复杂的循环例如WriterAgent觉得某部分信息不足可以请求ResearcherAgent进行补充调研。5.2 使用编排器实现任务流转在agentforge中你可以使用其Orchestrator或Workflow组件来管理这个流程。以下是一个简化的概念性代码示例async def blog_writing_workflow(forge, user_initial_request): 博客写作工作流 # 1. 获取各个智能体 analyst forge.get_agent(“AnalystAgent”) researcher forge.get_agent(“ResearcherAgent”) writer forge.get_agent(“WriterAgent”) # 2. 阶段一需求分析 print(“阶段一需求分析中...”) analysis_result await analyst.run(taskuser_initial_request) task_brief analysis_result[“response”] # 假设这里包含了结构化的任务概要 print(f“需求分析完成{task_brief[:200]}...”) # 3. 阶段二研究 print(“\n阶段二资料收集中...”) research_instruction f“根据以下任务概要搜集相关资料并整理成研究笔记\n{task_brief}” research_result await researcher.run(taskresearch_instruction) research_notes research_result[“response”] print(f“研究完成获得笔记长度{len(research_notes)} 字符”) # 4. 阶段三写作 print(“\n阶段三撰写草稿中...”) writing_instruction f“”” 任务概要 {task_brief} 研究笔记 {research_notes} 请根据以上材料撰写一篇技术博客文章初稿。要求结构清晰、语言通俗易懂。 “”” writing_result await writer.run(taskwriting_instruction) final_draft writing_result[“response”] print(“\n博客草稿撰写完成”) return final_draft在实际项目中这个流程会更复杂。你需要考虑错误处理某个Agent执行失败怎么办是否需要重试或转人工状态持久化长时间运行的工作流需要保存中间状态防止进程中断导致任务丢失。异步与并发如果多个任务间没有依赖可以让多个Agent并行执行以提高效率。agentforge可能提供了更高级的DSL领域特定语言或可视化工具来定义这类工作流但理解其基于代码的核心逻辑是进行自定义和调试的基础。5.3 智能体间的通信与共享记忆智能体之间如何传递信息除了通过编排器显式地传递任务结果如上面的task_brief,research_notes更重要的是共享的记忆空间。会话记忆的隔离与共享默认情况下每个智能体的会话记忆可能是隔离的。但在协作场景下你可以设计一个“共享会话”让参与同一工作流的智能体都能访问到之前的对话上下文。这可以通过配置记忆存储时使用相同的session_id来实现。长期记忆作为公共知识库所有智能体都连接到同一个长期记忆向量数据库。ResearcherAgent存储的研究成果WriterAgent可以直接检索使用。AnalystAgent总结的用户偏好也可以存入长期记忆供未来所有交互参考。通过消息总线通信更复杂的系统可能会引入一个轻量级的消息队列如Redis Pub/Sub智能体将执行结果和状态发布到特定频道其他感兴趣的智能体可以订阅。这种方式耦合度更低更易于扩展。一个重要的实践经验是在设计多智能体系统时要明确界定每个智能体的职责边界和输入输出格式。模糊的边界会导致智能体之间互相“踢皮球”或产生混乱的输出。使用结构化的数据格式如JSON在智能体间传递信息比纯文本更可靠。6. 性能调优、监控与问题排查当你的智能体系统从Demo走向实际应用性能、稳定性和可观测性就变得至关重要。以下是几个关键方面。6.1 性能优化策略LLM调用优化缓存对频繁出现的、结果确定的查询如“公司的核心价值观是什么”实施LLM响应缓存可以大幅减少API调用成本和延迟。可以使用langchain的缓存层或自建Redis缓存。批处理如果框架支持将多个独立的、小的文本处理任务如情感分析一批评论批量发送给LLM API比逐个调用更高效。模型选型不是所有任务都需要GPT-4。对于信息提取、简单分类等任务GPT-3.5-Turbo甚至更小的开源模型可能就足够了成本会显著降低。在agentforge配置中为不同智能体分配合适的模型。向量检索优化分块Chunking策略存储记忆时文本分块的大小和重叠度直接影响检索质量。对于一般知识256-512字符的分块比较通用对于代码或技术文档可能需要按函数或章节分块。需要根据内容类型调整。索引与过滤充分利用向量数据库的元数据过滤功能。在检索时除了向量相似度还可以用metadata如doc_type,date进行过滤快速缩小范围提升精度和速度。混合搜索结合关键词搜索BM25和向量搜索Embedding进行加权重排往往能取得比单一搜索更好的效果。一些向量数据库如Weaviate, Qdrant原生支持。智能体推理效率精简提示词Prompt避免在system_prompt中放入过多不必要的背景信息。清晰的指令比冗长的描述更有效。设置最大步数Max Steps对于循环推理如ReAct务必设置合理的最大步数防止智能体陷入“思考死循环”无谓消耗token。6.2 日志、监控与可观测性“智能体为什么做出了这个决策”这是调试中最头疼的问题。你需要建立完善的可观测性体系。结构化日志不要只用print。为框架集成像structlog或loguru这样的日志库记录每个关键事件的结构化信息。import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) # 在智能体执行关键动作时记录 async def agent_run_with_logging(agent, task): logger.info(“Agent started”, agent_nameagent.name, tasktask[:100]) start_time time.time() try: result await agent.run(task) duration time.time() - start_time logger.info(“Agent completed”, agent_nameagent.name, durationduration, successTrue) return result except Exception as e: logger.error(“Agent failed”, agent_nameagent.name, errorstr(e), exc_infoTrue) raise记录的内容应包括智能体名称、输入任务、调用的工具、工具返回、LLM的请求和响应可脱敏、最终输出、耗时等。链路追踪Tracing对于多智能体工作流需要一个唯一的trace_id贯穿整个请求。这能让你在日志中轻松过滤出一次用户查询所触发的所有智能体活动完整复现执行路径。可以考虑集成OpenTelemetry。关键指标监控业务指标任务成功率、平均处理时间、用户满意度如果有反馈。技术指标LLM API调用次数、token消耗量、向量检索延迟、工具调用失败率。成本指标按模型、按智能体细分的API调用成本。将这些日志和指标接入监控系统如Grafana Prometheus/Loki可以让你实时掌握系统健康度快速定位瓶颈。6.3 常见问题与排查清单在实际运行中你肯定会遇到各种问题。下面是一个快速排查清单问题现象可能原因排查步骤与解决方案智能体不调用工具1.system_prompt未明确指示。2. 工具描述不清晰LLM不理解何时用。3. 输出解析错误框架未识别出“Action”指令。1. 检查并强化prompt例如“你必须使用工具X来获取信息”。2. 优化工具描述使其更贴近LLM的理解方式。3. 查看智能体的原始输出日志确认其是否以框架期望的格式如Action: tool_name[input]发出了指令。向量检索结果不相关1. 文本分块不合理。2. Embedding模型不匹配。3. 检索时未使用元数据过滤。1. 调整分块大小和重叠度尝试不同的分块器。2. 对于专业领域考虑使用领域微调过的Embedding模型。3. 在存储时添加更丰富的元数据检索时结合过滤条件。多智能体协作混乱1. 智能体职责边界模糊。2. 传递的信息格式不统一。3. 缺乏共享上下文。1. 重新审查每个Agent的system_prompt确保其目标单一明确。2. 规定用JSON等结构化格式在智能体间传递数据。3. 为同一工作流下的智能体配置共享的会话记忆或工作区。LLM响应速度慢或超时1. 网络问题或API服务不稳定。2. Prompt过长或过于复杂。3. 未设置合理的超时时间。1. 实现重试机制和断路器模式。2. 精简Prompt移除冗余信息。3. 在代码中为LLM调用设置显式超时如asyncio.wait_for。成本失控1. 智能体陷入无意义循环。2. 未对简单任务使用轻量级模型。3. 重复处理相同内容。1. 严格设置最大推理步数或token限制。2. 建立模型路由策略根据任务复杂度选择模型。3. 对输入和LLM查询实施缓存。最后分享一个调试心得当智能体行为不符合预期时首先去检查它的完整输入Prompt和原始输出Completion日志。99%的问题都出在这里——要么是Prompt指令不清要么是输出解析有误。将LLM视为一个有些“死板”但能力强大的执行者你的指令必须足够精确、无歧义。