1. 从单兵作战到团队协作：AI Agent的协同困境与破局点

最近在折腾AI应用落地的过程中，我发现一个越来越明显的趋势：单个AI模型的能力边界正在被快速触及。无论是处理复杂工作流，还是应对需要多模态、多步骤推理的任务，一个“全能”的AI往往力不从心。这就好比让一个程序员同时负责前端、后端、运维和产品设计，效率和质量都很难保证。于是，我开始思考和实践一个更现实的路径：让多个AI智能体（Agent）协同工作，各司其职，形成“团队作战”的能力。

今天要聊的，就是一个具体的实践案例：如何让两个AI智能体高效协作。这个方案的灵感来源于一个实际需求：我需要一个能理解复杂指令、规划任务，并驱动另一个AI去具体执行的“大脑”和“手脚”。最终，我选择了用 QClaw 作为任务规划与决策中枢，来驱动 WorkBuddy 这个执行型AI进行具体操作。这不仅仅是两个工具的简单串联，而是一套关于角色定义、通信协议、状态管理和错误处理的完整协作框架。

在深入细节之前，我们先明确一下这两个角色的核心定位。 QClaw 在这里扮演的是“项目经理”或“指挥官”的角色。它的核心能力是理解用户的自然语言需求，进行任务分解、逻辑推理和步骤规划。它需要判断一个任务是否可行，应该拆分成哪几个子任务，这些子任务之间的依赖关系是什么，以及最终需要调用哪个“执行者”来完成。而 WorkBuddy 则更像是一个“高级执行专员”或“工具专家”。它擅长调用具体的API、操作软件、处理文档、生成内容或执行预设的自动化脚本。它接收来自QClaw的清晰、原子化的指令，并反馈执行结果。

这种“大脑+手脚”的协作模式，其价值在于突破了单一模型的局限性。QClaw不需要精通所有具体工具的操作细节，只需专注于规划和决策；WorkBuddy则无需理解过于模糊的宏观目标，只需高效、准确地完成被指派的单一任务。两者结合，实现了“1+1>2”的协同效应。接下来，我将从架构设计、通信实现、实战调优和避坑指南四个层面，详细拆解这套方案的搭建过程。

2. 架构蓝图：定义清晰的职责边界与通信接口

要让两个AI有效协作，首要任务不是写代码，而是画好“组织架构图”。我们必须为QClaw和WorkBuddy划定清晰的职责边界，并设计一套它们都能理解的“工作语言”（通信协议）。模糊的边界会导致指令混乱、责任推诿，最终协作失败。

2.1 角色能力画像与职责切分

首先，我们需要对两位“同事”进行精准的能力画像。

QClaw（指挥官）的核心职责：

  1. 意图理解与澄清 ：深度解析用户输入的模糊或复杂需求。例如，用户说“帮我分析一下上季度的销售数据，并做一份报告”，QClaw需要主动追问：“您指的是哪个产品线的数据？报告需要包含哪些维度（环比、同比、区域对比）？期望的输出格式是PPT、Word还是邮件正文？”
  2. 任务分解与规划 ：将宏观目标拆解为一系列顺序或并行的原子任务。继续上面的例子，它可能规划出：a) 从CRM系统获取原始销售数据；b) 进行数据清洗与格式化；c) 计算核心指标（销售额、增长率、完成率）；d) 生成图表；e) 撰写分析结论；f) 整合成报告文档。
  3. 执行者调度与指令生成 ：为每个原子任务分配合适的执行者（这里是WorkBuddy），并生成精确、无歧义的指令。例如，给WorkBuddy的指令不能是“处理数据”，而应该是“调用 data_clean 函数，处理 /path/to/sales_q3.csv 文件，移除空值，将‘日期’列转换为YYYY-MM-DD格式，输出到 /path/to/cleaned_data.csv ”。
  4. 状态监控与流程控制 ：接收WorkBuddy的反馈，判断任务成功、失败或需要异常处理。根据结果决定是继续下一步、重试当前步，还是整体流程回退。
  5. 结果汇总与交付 ：将所有子任务的结果整合，以用户期望的形式进行最终交付。

WorkBuddy（执行专员）的核心职责：

  1. 原子化指令执行 ：专注于完成一个具体的、明确的动作。它不需要理解整个项目的背景，只需要对接收到的指令负责。
  2. 工具/API调用 ：根据指令，调用其集成的各种工具，如Python脚本、Shell命令、Office套件API、数据库查询、网页自动化等。
  3. 结构化结果反馈 ：无论成功与否，都必须以预设的结构化格式（如JSON）向QClaw反馈。反馈中必须包含：任务ID、执行状态（成功/失败）、输出结果（或错误信息）、可能需要的后续建议。
  4. 有限度的异常处理 ：对于执行过程中可预见的、局部的错误（如文件暂时锁定、API短时超时），可以进行有限次数的重试。对于无法处理的错误，立即上报。

2.2 设计高效可靠的双向通信协议

通信协议是协作的基石。我放弃了简单的字符串拼接，采用了基于JSON Schema的结构化通信。这确保了指令和反馈的格式强一致，便于解析和验证。

指令下行格式（QClaw -> WorkBuddy）： 

{
  “task_id”: “TASK_20240415_001_001”,
  “command”: “generate_chart”,
  “parameters”: {
    “data_source”: “/path/to/cleaned_data.csv”,
    “chart_type”: “line”,
    “x_axis”: “month”,
    “y_axis”: “revenue”,
    “output_path”: “/path/to/charts/revenue_trend.png”
  },
  “context”: {
    “parent_task_id”: “TASK_20240415_001”,
    “step”: 4,
    “max_retry”: 2
  }
}
  • task_id : 全局唯一任务标识，用于追踪。
  • command : WorkBuddy可执行的动作名称，对应其内部的一个函数或工具。
  • parameters : 该动作所需的所有输入参数，必须详尽。
  • context : 上下文信息，帮助WorkBuddy了解自己在整体任务中的位置，以及重试策略等。

反馈上行格式（WorkBuddy -> QClaw）： 

{
  “task_id”: “TASK_20240415_001_001”,
  “status”: “success”, // 或 “failed”, “retrying”
  “output”: {
    “result_path”: “/path/to/charts/revenue_trend.png”,
    “message”: “图表已成功生成”
  },
  “error”: null, // 失败时填充错误详情
  “suggestion”: “下一步可以执行‘generate_report’命令整合图表” // 可选建议
}

注意 ：通信协议的设计必须前置。在开发初期，就要用JSON Schema或Pydantic模型严格定义好 command 的枚举值和每个 command 对应的 parameters 结构。这相当于为两个AI制定了严格的“合同”，能避免后期大量的调试和扯皮。

2.3 状态管理与数据持久化设计

一个复杂的任务流程可能包含几十个步骤，运行数小时。必须有一个中心化的状态管理器来记录每个任务的进度、结果和依赖关系。我通常采用一个轻量级的数据库（如SQLite）或一个状态文件（如JSON文件）来实现。

核心状态表（或结构）至少包含：

  • task_id : 主键。
  • parent_task_id : 父任务ID，用于构建任务树。
  • command : 执行的命令。
  • status : 当前状态（pending, running, success, failed, retrying）。
  • parameters : 输入参数的快照。
  • result : 执行结果的存储（或引用）。
  • created_at / updated_at : 时间戳。

QClaw在规划任务时，会初始化这个状态记录。WorkBuddy每执行完一步，就更新对应记录的状态和结果。QClaw通过轮询或事件监听的方式，获取最新状态，从而决定下一步动作。这种设计使得整个流程具备可观测性和可恢复性——即使程序中途崩溃，重启后也能从断点继续。

3. 核心实现：搭建QClaw与WorkBuddy的通信桥梁

理论架构清晰后，我们进入实战环节。这里的关键是让QClaw和WorkBuddy“说上话”。我将以Python环境为例，展示一个最简化的、但五脏俱全的实现方案。

3.1 QClaw侧：任务规划与指令派发引擎

QClaw的核心是一个循环： 解析用户输入 -> 规划任务 -> 派发指令 -> 等待反馈 -> 决策下一步 。这里，我利用LangChain的Agent框架来快速构建QClaw的“大脑”。

首先，定义QClaw可以使用的“工具”。这些工具本质上是对WorkBuddy能力的抽象描述。

from langchain.tools import BaseTool
from pydantic import BaseModel, Field
from typing import Type
import requests
import json

# 定义指令参数模型
class GenerateChartInput(BaseModel):
    data_source: str = Field(..., description=”原始数据文件的路径”)
    chart_type: str = Field(..., description=”图表类型，如 line, bar, pie”)
    x_axis: str = Field(..., description=”X轴对应的数据列名”)
    y_axis: str = Field(..., description=”Y轴对应的数据列名”)
    output_path: str = Field(..., description=”生成图表的保存路径”)

# 定义一个具体的工具：生成图表
class GenerateChartTool(BaseTool):
    name = “generate_chart”
    description = “根据提供的数据文件生成指定类型的图表”
    args_schema: Type[BaseModel] = GenerateChartInput

    def _run(self, data_source: str, chart_type: str, x_axis: str, y_axis: str, output_path: str):
        “”“调用WorkBuddy API执行生成图表命令”“”
        # 构造指令
        command_payload = {
            “task_id”: f”CHART_{int(time.time())}”, # 简单生成任务ID
            “command”: “generate_chart”,
            “parameters”: {
                “data_source”: data_source,
                “chart_type”: chart_type,
                “x_axis”: x_axis,
                “y_axis”: y_axis,
                “output_path”: output_path
            }
        }
        # 假设WorkBuddy的API监听在本地5001端口
        response = requests.post(“http://localhost:5001/execute”, json=command_payload, timeout=30)
        result = response.json()
        
        if result.get(“status”) == “success”:
            return f”图表已成功生成，保存于：{result[‘output’].get(‘result_path’)}”
        else:
            return f”图表生成失败：{result.get(‘error’)}”

    def _arun(self, query: str):
        raise NotImplementedError(“此工具不支持异步”)

类似地，我们可以定义 FetchDataTool 、 CleanDataTool 、 WriteReportTool 等。这些工具就是QClaw指挥WorkBuddy的“遥控器”。

接下来，初始化QClaw（以使用OpenAI模型为例）：

from langchain.agents import initialize_agent, AgentType
from langchain.chat_models import ChatOpenAI
from langchain.memory import ConversationBufferMemory

llm = ChatOpenAI(model=”gpt-4”, temperature=0) # 使用低temperature保证规划稳定性
tools = [GenerateChartTool(), FetchDataTool(), CleanDataTool()] # 导入所有定义好的工具
memory = ConversationBufferMemory(memory_key=”chat_history”, return_messages=True)

# 创建Agent
qclaw_agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION, # 适合结构化工具调用的Agent类型
    verbose=True,
    memory=memory,
    handle_parsing_errors=True # 重要！处理解析错误
)

现在，QClaw就具备了根据用户目标，自动选择并调用相应工具（即向WorkBuddy发送指令）的能力。

3.2 WorkBuddy侧：指令接收与可靠执行器

WorkBuddy是一个独立的服务，它暴露一个API端点（如 /execute ），专门接收并处理来自QClaw的指令。我使用FastAPI来快速搭建这个服务。

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import subprocess
import json
import asyncio
from typing import Optional

app = FastAPI()

# 定义请求/响应模型
class TaskRequest(BaseModel):
    task_id: str
    command: str
    parameters: dict
    context: Optional[dict] = None

class TaskResponse(BaseModel):
    task_id: str
    status: str # success, failed
    output: Optional[dict] = None
    error: Optional[str] = None
    suggestion: Optional[str] = None

# 核心执行路由
@app.post(“/execute”, response_model=TaskResponse)
async def execute_task(request: TaskRequest):
    task_id = request.task_id
    command = request.command
    params = request.parameters
    
    try:
        # 根据command路由到不同的执行函数
        if command == “generate_chart”:
            result = await _generate_chart(**params)
        elif command == “fetch_data”:
            result = await _fetch_data(**params)
        elif command == “clean_data”:
            result = await _clean_data(**params)
        else:
            return TaskResponse(
                task_id=task_id,
                status=”failed”,
                error=f”未知命令：{command}”
            )
        
        # 假设执行函数返回一个包含结果的字典
        return TaskResponse(
            task_id=task_id,
            status=”success”,
            output=result
        )
        
    except Exception as e:
        # 记录详细日志
        print(f”任务 {task_id} 执行失败: {str(e)}”)
        return TaskResponse(
            task_id=task_id,
            status=”failed”,
            error=str(e),
            suggestion=”请检查输入参数是否正确，或重试该操作。”
        )

# 具体的执行函数示例
async def _generate_chart(data_source: str, chart_type: str, x_axis: str, y_axis: str, output_path: str):
    “”“调用Python的matplotlib或seaborn库生成图表”“”
    # 这里是一个简化示例，实际中可能是一个复杂的脚本
    import pandas as pd
    import matplotlib.pyplot as plt
    
    df = pd.read_csv(data_source)
    plt.figure(figsize=(10, 6))
    
    if chart_type == “line”:
        plt.plot(df[x_axis], df[y_axis])
    elif chart_type == “bar”:
        plt.bar(df[x_axis], df[y_axis])
    # ... 其他图表类型
    
    plt.title(f”{y_axis} by {x_axis}”)
    plt.xlabel(x_axis)
    plt.ylabel(y_axis)
    plt.tight_layout()
    plt.savefig(output_path)
    plt.close()
    
    return {“result_path”: output_path, “message”: “Chart generated successfully”}

# 其他执行函数 _fetch_data, _clean_data 等...

运行这个FastAPI应用（ uvicorn workbuddy:app --host 0.0.0.0 --port 5001 ），WorkBuddy服务就启动了。它静静地等待QClaw发来的指令，执行，并返回结构化的结果。

3.3 连接与测试：完成第一次“对话”

现在，让我们启动两个服务，并进行一次端到端测试。

  1. 启动WorkBuddy ：在终端A运行 uvicorn workbuddy:app --host 0.0.0.0 --port 5001 。
  2. 启动QClaw交互 ：在Python环境或另一个终端中，运行你的QClaw脚本。
  3. 发出指令 ：向QClaw提出一个复杂需求。
# 模拟用户输入
user_query = “帮我分析一下‘sales_data.csv’文件，生成一个关于每月销售额的折线图，保存为‘monthly_sales.png’。”
response = qclaw_agent.run(user_query)
print(response)

QClaw的思考过程（verbose模式下可见）可能会是这样的：

  • 思考 ：用户需要分析销售数据并生成图表。我需要先获取数据，但用户已经提供了文件路径。所以第一步是检查并清理数据（如果需要），第二步是生成折线图。
  • 行动 ：调用 clean_data 工具，参数为 data_source=’sales_data.csv’ 。
  • 观察 ：WorkBuddy返回“数据清洗成功，路径为 cleaned_sales.csv ”。
  • 思考 ：数据已准备好，现在可以生成图表了。
  • 行动 ：调用 generate_chart 工具，参数为 data_source=’cleaned_sales.csv’ , chart_type=’line’ , x_axis=’month’ , y_axis=’sales’ , output_path=’monthly_sales.png’ 。
  • 观察 ：WorkBuddy返回“图表已成功生成，保存于：monthly_sales.png”。
  • 最终回答 ：用户，已完成您的请求。已对‘sales_data.csv’文件进行清洗，并生成了每月销售额的折线图，文件为‘monthly_sales.png’。

至此，两个AI完成了第一次成功的协作。QClaw负责了理解和规划，WorkBuddy负责了具体的执行。

4. 进阶调优：提升协作的鲁棒性与效率

基础链路跑通只是第一步。要让这个协作系统真正可靠、高效地用于生产，还需要在以下几个方面进行深度优化。

4.1 实施复杂的错误处理与重试机制

在实际运行中，失败是常态。网络波动、资源锁、API限流、临时文件冲突等都可能导致单次执行失败。一个健壮的系统必须能优雅地处理这些错误。

在WorkBuddy侧实现“战术级”重试 ：对于某些可预见的临时性错误，应在执行函数内部实现重试。例如，调用一个外部API时，使用 tenacity 库。

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(3), # 最多重试3次
    wait=wait_exponential(multiplier=1, min=2, max=10), # 指数退避等待
    retry=retry_if_exception_type((requests.ConnectionError, requests.Timeout)) # 仅对网络错误重试
)
def call_unstable_api(url):
    response = requests.get(url, timeout=5)
    response.raise_for_status()
    return response.json()

在QClaw侧实现“战略级”决策 ：WorkBuddy上报失败后，QClaw不能简单地停止或盲目重试。它需要根据错误类型做出决策。这需要在工具调用层增加更复杂的逻辑。

def _run_with_fallback(self, …):
    try:
        # 主逻辑
        return self._call_workbuddy(…)
    except SpecificError1:
        # 尝试备用方案A
        return self._fallback_method_a(…)
    except SpecificError2:
        # 如果错误是参数问题，则修正参数后重试
        corrected_params = self._correct_params(…)
        return self._call_workbuddy(…, corrected_params)
    except Exception as e:
        # 无法处理的错误，向上抛出，由QClaw的Agent决定是否询问用户
        raise

同时，在QClaw的Agent初始化时，可以设置 max_iterations 和 early_stopping_method 来防止任务规划进入死循环。

4.2 设计上下文传递与共享记忆

在复杂的多步骤任务中，前一步的输出往往是后一步的输入。例如，数据清洗后的文件路径，需要传递给图表生成步骤。我们需要一种机制来传递这个上下文。

方案一：通过状态管理器传递 。QClaw在派发任务时，可以将上一步的结果（从状态管理器中查询）作为参数的一部分，填入当前指令的 parameters 中。这要求QClaw的规划逻辑能动态地构建参数。

方案二：设计共享工作空间 。约定一个临时目录或一个云存储路径作为共享空间。每个任务将其输出（如文件）保存到一个以 task_id 命名的子目录中。后续任务通过 parent_task_id 来定位所需的输入文件。这种方式耦合度更低，但需要更严谨的目录管理规范。

在我的实践中，我通常混合使用两种方式：对于简单的字符串或数值结果，通过状态管理器传递；对于文件类输出，使用共享工作空间，并在指令参数中传递文件路径。

4.3 性能优化与异步通信

当任务步骤很多时，同步等待每一步完成会严重拖慢整体流程。我们需要引入异步机制。

WorkBuddy侧 ：FastAPI本身支持异步请求处理（如上文代码中的 async def ）。确保你的执行函数（如 _generate_chart ）也是异步的，或者在同步函数中正确使用 run_in_executor 来避免阻塞事件循环。

QClaw侧 ：LangChain的Agent默认是同步的。对于可以并行执行的无依赖任务，一个进阶方案是，QClaw在规划阶段识别出可以并行的任务组，然后使用 asyncio.gather 并发地调用多个工具。这需要对Agent的执行流程进行更底层的定制。一个更简单的折中方案是，让WorkBuddy的服务本身具备并行处理多个请求的能力（通过多进程/线程池），这样即使QClaw顺序调用，后端也能并发执行，提高吞吐量。

4.4 可观测性与日志记录

系统复杂后，排错离不开完善的日志。你需要记录：

  • QClaw的决策日志 ：用户原始输入、Agent的思考过程（Chain of Thought）、每一步选择的工具和参数。
  • 指令流水日志 ：每个 task_id 的指令内容、派发时间、目标端点。
  • WorkBuddy执行日志 ：接收到的指令、开始执行时间、执行过程的关键节点、结束状态、产生的错误堆栈。
  • 通信日志 ：所有HTTP请求和响应的原始数据（可脱敏）。

建议使用结构化的日志系统（如 structlog 或 logging 配合JSON Formatter），并将日志统一收集到ELK或类似平台，方便查询和关联分析。为每个 task_id 或整个会话（ session_id ）添加唯一标识，贯穿所有日志，是快速定位问题的关键。

5. 实战避坑：从理想架构到稳定落地的关键细节

纸上得来终觉浅，绝知此事要躬行。在将这套方案投入实际使用的过程中，我踩过不少坑，也积累了一些让协作从“能跑通”到“跑得稳”的关键经验。

5.1 指令的模糊性与“语义鸿沟”

最大的挑战来自于QClaw生成的指令，在WorkBuddy看来可能依然是模糊的。例如，QClaw可能生成指令 {“command”: “analyze_sentiment”, “parameters”: {“text”: “这个产品简直太糟糕了，我永远不会再买。”}} 。但 analyze_sentiment 这个命令对WorkBuddy来说，需要更精确的定义：是用哪个情感分析模型？输出是积极/消极/中性三分类，还是0-1的分数？输出格式是什么？

解决方案 ：

  1. 极度原子化的命令设计 ：不要设计 analyze_sentiment 这种大而化之的命令。而是设计 call_bert_sentiment_classification 或 call_vader_sentiment_analysis ，并在工具描述和参数模型中明确其输入输出。这限制了QClaw的灵活性，但换来了极高的可靠性。
  2. 强化工具描述（description） ：在定义QClaw的工具时， description 字段要写得极其详尽和精确，说明这个工具 具体 做什么、输入 必须 是什么格式、输出 一定 是什么。这能极大地引导LLM正确使用工具。
  3. 引入“验证层” ：在WorkBuddy的API入口处，增加一个参数验证层。使用Pydantic模型对每个 command 的 parameters 进行强制校验，类型不对、字段缺失、值域不符的请求直接拒绝，并返回清晰的错误信息给QClaw。这迫使QClaw必须生成格式完全正确的指令。

5.2 长流程中的状态一致性与回滚

当一个包含10个步骤的任务执行到第8步失败时，怎么办？全部重来显然浪费，手动干预又失去了自动化的意义。

解决方案 ：实现 有状态的、可补偿的工作流 。

  • 状态持久化 ：如前所述，每个任务步骤的状态必须持久化到数据库。
  • 定义“补偿动作” ：为每个可能产生副作用的命令（如创建文件、写入数据库、发送邮件）设计一个反向操作的“补偿命令”。例如， create_file 的补偿命令是 delete_file 。
  • 实现工作流引擎 ：QClaw不再仅仅是顺序派发指令，而是维护一个工作流DAG（有向无环图）。当某个节点失败时，工作流引擎根据策略（如“重试3次后失败”）触发回滚流程，自动逆向执行该节点之前已成功节点的补偿动作，将系统状态回退到安全点。这是一个相对复杂的实现，但对于金融、订单处理等关键场景是必须的。初期可以使用简单的“标记失败点，人工介入”策略。

5.3 资源竞争与并发控制

如果多个用户同时发起请求，QClaw可能会同时派发大量任务给WorkBuddy，可能导致资源（CPU、内存、文件锁、API调用额度）竞争。

解决方案 ：

  1. 队列化 ：在QClaw和WorkBuddy之间引入一个消息队列（如Redis Queue, RabbitMQ）。QClaw将指令发布到队列，WorkBuddy作为消费者从队列拉取任务执行。这样可以平滑流量，实现削峰填谷，并方便扩展多个WorkBuddy worker。
  2. 资源池与限流 ：在WorkBuddy内部，对消耗特定资源的操作（如调用某昂贵API）使用连接池或信号量进行限流，防止单个任务拖垮整个系统。
  3. 任务优先级 ：在指令中增加 priority 字段，并在队列或调度器中实现优先级调度，确保重要任务优先执行。

5.4 成本与延迟的权衡

使用强大的LLM（如GPT-4）作为QClaw的“大脑”，每次规划和工具调用都会产生Token消耗和网络延迟。对于简单任务，这可能“杀鸡用牛刀”。

优化策略 ：

  1. 任务复杂度判断 ：在QClaw前端做一个轻量级过滤器。对于非常明确、格式固定的指令（如“翻译这句话：Hello World”），可以直接路由给一个专用的简单处理模块，绕过完整的Agent规划流程。
  2. 缓存规划结果 ：对于常见的、重复性的任务模式，可以将QClaw的完整规划过程（从用户输入到最终的工具调用序列）缓存起来。下次遇到相似输入时，直接使用缓存结果，省去LLM推理的开销。可以使用输入文本的语义哈希作为缓存键。
  3. 使用轻量级模型 ：对于执行结果验证、简单决策等环节，可以尝试使用更小、更快的本地模型（如通过Ollama部署的Llama 3等），只在需要复杂推理和规划时调用大模型。

经过以上四个层面的构建和优化，一个由QClaw驱动WorkBuddy的AI协作系统就从概念变成了一个稳定、可靠、可扩展的生产力工具。它不再是两个AI的简单连接，而是一个具备明确分工、健壮通信、错误处理和资源管理能力的智能体协同体系。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

百万Token不是数字游戏：Kimi K3完整吞下10万行代码库后，我测出了它的真实理解力

avatar 亚马逊云科技技术品牌专区
cover

【2026最新版】Codex换肤助手下载和使用教程：一键美化 Codex 客户端，支持自定义主题

avatar 亚马逊云科技技术品牌专区

FastAPI + OpenAI 兼容协议 + DeepSeek 实战：大模型 Function Calling 工具调用全拆解

模型本身不能直接查天气、查数据库。我们告诉模型"你有这些函数可用"，模型在觉得需要时返回"我想调用某个函数、参数是这样"，真正的函数由我们本地执行，再把结果交还给模型整理成话。这就是"模型决策 + 本地执行"的混合模式。

avatar 亚马逊云科技技术品牌专区