基于LLM的Agent协作系统：从中心化调度到去中心化协商的工程实践

1. 项目概述：从单兵作战到团队协作的范式转变

在软件开发这个行当里待久了，你肯定经历过这样的场景：为了调试一个复杂的线上问题，你需要在终端里敲命令看日志，切到浏览器查文档，打开IDE改代码，再切回终端重启服务。几个窗口来回切换，脑子里的上下文也跟着不断刷新，效率低不说，还特别容易出错。这本质上是一种“单兵作战”的模式，程序员作为唯一的“智能体”，需要手动串联起所有工具和流程。

而“Agent协作”这个概念，正是为了解决这种低效而生的。它不是一个具体的工具，而是一种工作范式。简单来说，就是把那些重复、繁琐、需要多步骤联动的任务，交给一组专门化的、可以相互通信和协作的“智能代理”去完成。你，作为“指挥官”，只需要下达一个高级别的目标指令，比如“分析一下昨天订单服务响应变慢的根本原因并给出修复方案”，剩下的数据收集、日志分析、代码审查、报告生成等一系列动作，由多个Agent各司其职、协同完成。

这听起来有点像科幻电影里的场景，但实际上，随着大语言模型能力的爆发和各类AI工具API的成熟，构建这样的协作系统已经不再是空中楼阁。我最近就在团队内部实践了一套轻量级的Agent协作流程，它没有依赖任何庞大的商业平台，而是用我们熟悉的脚本、开源模型和API“攒”出来的。这套方式的核心不是追求全自动的“黑箱魔法”，而是追求一种“增强智能”——让AI成为我们得力的副驾驶和协作者，把我们从重复劳动中解放出来，专注于更需要创造力和判断力的核心工作。

2. 协作框架的设计思路：从“中心化调度”到“去中心化协商”

在设计Agent协作系统时，第一个要回答的问题就是：Agent之间如何沟通和协作？市面上主流的有两种思路，我们实践后认为，对于程序员团队，后一种更具灵活性和鲁棒性。

2.1 中心化调度器模式及其局限

最初我们尝试的是类似“导演-演员”的中心化模式。我们设计了一个核心的“调度Agent”（Orchestrator），它负责解析用户的任务，将其拆解成子任务，然后像项目经理一样，依次调用不同的“技能Agent”（Skill Agent），比如“代码分析Agent”、“日志查询Agent”、“API测试Agent”等。

这个模式的流程很清晰：

1. 用户向调度Agent提出请求：“为什么用户登录会失败？”
2. 调度Agent分析后，制定计划：先让“日志查询Agent”去检索相关错误日志；拿到日志后，让“代码分析Agent”定位可能出错的代码段；最后让“测试Agent”模拟场景验证。
3. 调度Agent严格按照计划，同步、顺序地调用各个技能Agent，并汇总它们的结果。

这个模式实现起来相对简单，用Python写一个主循环，配合if-else或者简单的规则引擎就能搭起来。但它有个致命的缺点：僵化。一旦任务流偏离预设剧本，整个系统就卡住了。比如，日志Agent返回“没有找到相关错误”，调度器可能就不知道下一步该调用谁了，它缺乏动态调整计划的能力。这就像是一个只会按剧本念词的导演，演员一即兴发挥，戏就演不下去了。

2.2 基于共享工作空间与发布订阅的协商模式

我们最终采用的，是一种更接近“去中心化团队”的协商模式。这个模式的核心是两个概念：共享工作空间（Shared Workspace）和发布-订阅（Pub/Sub）机制。

共享工作空间，可以理解为一个所有Agent都能读写的中共白板或项目看板（比如一个特定的数据库表、一个共享文件夹，或者一个内存中的对象）。这个空间里存放着任务的总目标、当前状态、已收集的信息、中间结论和待解决的问题。每个Agent的工作成果都更新在这里。

发布-订阅机制，则是Agent之间的通信总线。当一个Agent完成了某项工作（比如找到了错误日志），它不会直接呼叫下一个Agent，而是在总线上“发布”一个事件，比如event: logs_analyzed, result: “发现数据库连接超时错误”。其他关心这类事件的Agent（比如“数据库诊断Agent”和“代码修复建议Agent”）会“订阅”这些事件类型。一旦事件发布，相关的Agent就会自动被唤醒，去查看共享工作空间中的最新上下文，然后开始自己的工作。

这么做的好处显而易见：

• 灵活性高：工作流不是预设的，而是动态涌现的。数据库诊断Agent和代码修复Agent可以同时被日志分析结果触发，并行工作，最后把各自的诊断和建议都放到工作空间。
• 鲁棒性强：如果一个Agent失败了或者没有产出，其他Agent可以根据工作空间中已有的其他信息继续推进，或者发布一个help_needed事件来寻求协作。
• 易于扩展：要增加一个新的Agent（比如一个“性能瓶颈分析Agent”），你只需要让它订阅相关的事件（如event: service_slow），并教会它如何读写共享工作空间即可，无需修改核心调度逻辑。

在我们的实践中，我们用Redis来实现这个共享工作空间和Pub/Sub总线。Redis的List和Sorted Set可以很好地存储任务队列和带优先级的信息，而其自带的Pub/Sub功能完美契合了我们的通信需求。整个系统的架构变得非常清爽，核心就是一个事件循环，监听Redis频道，将事件分发给注册的Agent处理函数。

注意：选择Redis是因为它简单高效，且为很多程序员所熟悉。如果你的协作逻辑极其复杂，需要考虑工作流持久化、分布式事务，那么可以评估像Camunda、Temporal这类工作流引擎，但初期切忌过度设计。

3. 核心Agent的角色定义与能力建设

框架搭好了，接下来就是招募“团队成员”——定义各个Agent的角色和能力。我们的原则是：高度专业化、能力可评估、交互有规范。切忌打造一个“全能但平庸”的超级Agent。

3.1 专业化分工：定义清晰的Agent角色

我们初期设定了四个核心Agent角色，它们构成了处理大多数研发问题的“最小可行团队”：

1. 需求解析与任务规划Agent（Planner）：

   • 职责：它是与用户对话的“接口”，负责将用户模糊、口语化的需求，转化为清晰、可执行的任务描述，并初始化共享工作空间。例如，用户说“登录好像有点慢”，它会将其解析为：“目标：诊断用户登录接口性能下降问题。初始上下文：涉及auth-service，时间范围最近24小时。”
   • 能力核心：Prompt工程。它的系统指令（System Prompt）必须明确包含角色定义、输出格式规范（必须是结构化的JSON，包含task_title,success_criteria,initial_context等字段），以及追问澄清的规则。

2. 信息搜集Agent（Investigator）：

   • 职责：团队的“眼睛”和“耳朵”。负责从各种外部系统抓取信息，填充到共享工作空间。它的能力不是“分析”，而是“准确获取”。
   • 技能装备：这是我们为Agent“安装工具”的关键体现。我们为它集成了：
     • 命令行工具：通过封装subprocess模块，使其能安全地执行grep,kubectl logs,jq等命令来查询日志和系统状态。
     • 内部API调用：使用requests库，赋予其调用公司内部监控系统（如Prometheus）、项目管理（如Jira）、源码库（如GitLab API）的权限。
     • 网页抓取与摘要：对于需要参考外部文档（如官方文档、Stack Overflow）的情况，我们集成playwright进行自动化浏览，并用LLM进行关键信息摘要。
   • 实操心得：权限控制是重中之重。必须为这个Agent创建一个权限最小化的系统账号或API Token，并且所有执行命令或调用API的操作，都必须有严格的输入校验和超时限制，防止任意命令执行漏洞。

3. 分析与诊断Agent（Analyst）：

   • 职责：团队的“大脑”。它不直接接触外部系统，只阅读共享工作空间中由Investigator收集来的原始数据（日志、指标、代码片段），进行分析、推理、归纳，提出假设性结论。
   • 能力核心：上下文理解与逻辑链。它的Prompt需要强调“基于以下证据进行分析”、“给出可能性从高到低的三个假设”、“每一步推理需引用数据来源”。例如，面对一堆日志，它的输出可能是：“假设1（概率70%）：数据库连接池耗尽。证据：日志中频繁出现‘Connection timeout’错误（见数据块#Log-12），且该错误出现频率与登录请求量曲线高度吻合（见数据块#Metric-5）。”

4. 执行与验证Agent（Executor）：

   • 职责：团队的“双手”。负责执行具体的、低风险的修复或验证动作。
   • 典型任务：
     • 代码操作：根据Analyst的建议，在特定分支上创建修复Commit（调用Git API）。
     • 配置变更：在测试环境，通过配置中心API调整某个服务的超时参数。
     • 验证测试：执行一套预定义的API测试脚本，验证修复是否有效。
   • 安全红线：这个Agent的行动必须被限制在非生产环境，并且所有执行动作前，必须生成清晰的、可读的“执行计划”供人类确认（例如，“我将在feature/fix-db-pool分支上修改application.yml中的maxPoolSize从10到20”），采用“人类确认-机器执行”的协作模式。

3.2 Agent的“记忆”与上下文管理

单个LLM调用是无状态的。为了让Agent在复杂的多轮协作中保持“记忆”，我们需要为它们设计上下文管理机制。我们采用了一种分层级的上下文管理：

1. 工作空间记忆（长期/共享记忆）：所有Agent的产出都结构化后存入Redis共享空间。这是任务的全局状态。
2. 会话记忆（中期/私有记忆）：每个Agent在处理一个具体事件时，需要知道自己之前在这个任务里做过什么。我们为每个Agent实例维护一个会话缓存，将本次交互的历史消息（用户指令、工具调用结果、LLM回复）保存起来，在下次被同一任务触发时作为上下文传入。这通常通过像LangChain的ConversationBufferMemory这样的组件实现。
3. 工具使用记忆：对于Investigator和Executor，它们调用工具的历史（命令、参数、结果、状态码）也需要被记录，这不仅用于调试，也可以在后续步骤中作为参考信息。

管理这些记忆的关键是摘要和修剪。当对话轮次或工作空间内容过多时，不能无脑地将所有历史都塞给LLM（会超出Token限制且干扰重点）。我们需要一个“摘要Agent”（或一个摘要函数），定期将冗长的原始数据（如大段日志）和分析过程，提炼成简洁的要点和结论，更新到工作空间的核心结论区，替换掉过于细节的原始数据。

4. 实践流程：一次完整的故障诊断协作实录

理论说了这么多，我们来看一个真实发生的简化案例，展示这套系统是如何运作的。问题是：“今天下午开始，用户反馈商城首页加载缓慢。”

4.1 阶段一：任务初始化与信息搜集

1. 用户触发：我在团队Chatbot中输入：“首页加载慢，查一下原因。”
2. Planner启动：Planner Agent被触发。它通过LLM生成结构化任务描述，写入Redis工作空间：

   { “task_id”: “diagnose_20231027_001”, “description”: “诊断商城首页（`/home`接口）性能下降问题”， “scope”: “服务: frontend-service, gateway-service; 时间: 2023-10-27 14:00 至今”, “success_criteria”: “定位到导致性能下降的主要根因，并提供至少一个可行的缓解或修复建议。” }

   同时，Planner发布首个事件：event: task_created, data: {task_id: “diagnose_20231027_001”}。
3. Investigator响应：订阅了task_created事件的Investigator被唤醒。它读取工作空间中的任务描述，开始并行搜集信息：
   • 调用监控API：获取frontend-service和gateway-service在目标时间段的CPU、内存、QPS、平均响应时间（P99）指标图表数据。
   • 查询日志：通过ES（Elasticsearch）API，检索这两个服务在目标时间段内ERROR和WARN级别的日志，并按出现频率排序。
   • 检查依赖：调用服务网格或注册中心API，获取frontend-service下游依赖的服务列表（如product-service,recommendation-service）。 Investigator将所有这些原始数据，以清晰的标题（如[Metric] frontend-service RT、[Log] gateway-service errors）和结构化格式（尽量用JSON或表格）存入工作空间，并发布事件：event: initial_investigation_complete。

4.2 阶段二：分析与诊断推理

1. Analyst登场：订阅了initial_investigation_complete事件的Analyst开始工作。它从工作空间读取所有原始数据。假设它看到：
   • gateway-service的P99响应时间从200ms飙升至2s。
   • 日志中大量出现“upstream request timeout”错误。
   • frontend-service自身指标正常，但其下游的recommendation-service的P99响应时间高达5s。
2. Analyst推理：Analyst调用LLM，基于以上证据进行推理。它的输出可能如下：

   分析结论： 主要根因假设：首页加载慢的瓶颈很可能在于推荐服务（recommendation-service）响应缓慢，导致网关（gateway-service）在代理请求时超时。 推理链： 1. 网关服务日志显示“上游请求超时”，直接指向其后端服务响应慢。 2. 前端服务自身指标正常，排除其本身问题。 3. 下游服务中，推荐服务的P99响应时间异常高（5s），与网关超时时间（默认2s）吻合，嫌疑最大。 4. 需要进一步调查推荐服务性能下降的原因。 建议下一步行动： 1. 深入调查recommendation-service：收集其详细指标、日志、近期变更。 2. 检查其自身依赖（如数据库、缓存）或是否存在热点数据。

   Analyst将此结论写入工作空间的“分析结论”区，并发布事件：event: root_cause_hypothesized, data: {suspect_service: “recommendation-service”}。

4.3 阶段三：深入调查与执行验证

1. Investigator再次行动：它订阅了root_cause_hypothesized事件。看到嫌疑目标是recommendation-service，它自动启动第二轮深度调查：
   • 获取该服务的详细资源使用率、垃圾回收情况。
   • 查询其访问日志，分析请求路径、参数是否存在模式（例如，是否某个特定商品ID的推荐查询特别慢）。
   • 检查该服务最近一次的部署记录（调用GitLab和K8s API）。
2. Analyst二次诊断：Investigator发布event: deep_dive_data_ready后，Analyst再次分析新数据。假设这次发现：该服务内存使用率持续高于90%，且GC频繁；日志中大量出现“Full GC”字样；最近一次部署在问题发生前2小时，引入了一个新的、未经过充分压测的推荐算法模型。
3. 生成解决方案：Analyst综合信息，给出更具体的诊断和方案：“高度确信是推荐服务新部署的v1.2版本算法模型内存占用过高，导致频繁Full GC，引发全局停顿。建议：1. 立即回滚至v1.1版本（短期）。2. 优化新算法模型的内存效率，并进行压测后重新发布（长期）。”
4. Executor介入（需人工确认）：Planner或人类工程师根据Analyst的结论，可以手动触发Executor。Executor生成清晰的回滚执行计划：“将在recommendation-service的K8s部署中，将镜像标签从v1.2改为v1.1，并重启Pod。” 这个计划会通过Chatbot发送给负责人确认。负责人点击“确认”后，Executor才调用Kubernetes API执行回滚操作。
5. 验证与闭环：回滚后，Investigator自动监控相关指标。当检测到recommendation-service和gateway-service的响应时间恢复正常后，发布event: issue_resolved。Planner或一个专门的Reporter Agent可以汇总整个任务的所有信息（问题、分析过程、根因、执行动作、结果），生成一份完整的诊断报告，发送到频道或知识库，形成闭环。

5. 关键实现细节与避坑指南

搭建这样一套系统，在实现层面有很多细节决定成败。以下是我们踩过坑后总结的关键点。

5.1 Agent间通信协议的设计

Agent不能靠“自然语言”闲聊来协作，必须定义严格的通信协议。我们设计了一个轻量级的JSON协议：

{ “event_type”: “logs_analyzed”, // 事件类型，枚举值 “task_id”: “diagnose_20231027_001”, // 关联的任务ID “producer”: “investigator_agent”, // 事件生产者 “timestamp”: 1698412345.678, “data”: { // 事件负载，结构因事件类型而异 “findings”: [ { “service”: “gateway”, “log_level”: “ERROR”, “pattern”: “upstream request timeout”, “count”: 1245 } ], “data_references”: [“workspace:log_block_1”] // 指向工作空间中具体数据块的指针 } }

这个协议的关键字段是event_type和data_references。event_type驱动了Pub/Sub的订阅关系；data_references避免了在事件中传输大量数据，而是采用“指针”模式，让消费者按需去共享工作空间读取，保证了事件总线的轻量和高效。

5.2 工具调用（Function Calling）的稳定化实践

让Agent可靠地调用外部工具（API、命令行）是整个系统能落地的基石。大语言模型的“函数调用”能力有时并不稳定，可能格式错误或产生幻觉。我们采用了“双保险”策略：

1. 结构化输出强制：在调用LLM的API时，严格使用response_format参数（如OpenAI的JSON Schema模式）来约束输出格式。告诉模型“你必须返回一个符合这个JSON Schema的对象”，这比在Prompt里用文字描述有效得多。
2. 后置解析与重试：即使使用了结构化输出，我们仍然在代码层面对LLM的返回进行解析和校验。如果解析失败，不是直接报错，而是将错误信息连同原始Prompt和上下文，重新构造一个“修正请求”发送给LLM。例如：“你刚才的回复无法被解析为有效的工具调用请求，错误是：XXX。请严格按照以下格式重新输出。” 通常最多重试一次就能成功。

5.3 成本、延迟与错误处理

• 成本控制：LLM API调用是主要成本。我们实施了以下策略：
  • 缓存：对Investigator获取的、短期内不会变化的数据（如文档、配置），进行结果缓存。
  • 模型分级：对Planner和Analyst这类需要复杂推理的Agent，使用GPT-4等高级模型；对Investigator中简单的信息提取摘要，或Executor中生成固定模板文本，使用成本更低的Claude Haiku或GPT-3.5-Turbo。
  • Token限制：严格限制每次请求的max_tokens，并为上下文窗口设置合理的截断策略。
• 延迟优化：协作的步骤多了，延迟可能叠加。我们通过异步化和并行化来优化：
  • 所有Agent的事件处理都是异步的，避免阻塞。
  • Investigator在搜集不同来源的信息时，只要不相互依赖，就使用asyncio.gather并发执行。
  • 对于不要求严格顺序的后续分析，可以同时触发多个Analyst从不同角度分析（如一个分析性能，一个分析错误日志）。
• 错误处理与降级：
  • Agent超时：每个Agent任务都有超时设置，超时后发布event: agent_timeout，由监控系统告警，并可能触发备用Agent或通知人工。
  • 工具调用失败：工具调用（如API请求）必须有完备的重试机制（如指数退避）和失败回调。失败信息应作为有效“数据”存入工作空间（例如，“调用监控系统API失败，原因：网络超时”），供其他Agent参考。
  • 人工接管通道：在任何阶段，都可以通过向工作空间写入一条“human_intervention_required”事件来暂停自动化流程，并附上当前所有上下文，等待工程师介入。

6. 从实践到演进：衡量效果与未来展望

这套系统运行一段时间后，我们如何衡量其效果？它又该往何处去？

6.1 效果评估与度量

不能只凭感觉说“有用”，我们设定了几个关键指标：

• 平均诊断时间（MTTD）：从问题发生（或被提出）到根因被定位的平均时间。这是我们最关注的效率指标。
• 人工介入率：有多少比例的诊断任务需要人工中途介入或最终接手。这衡量了系统的自动化程度和可靠性。
• 任务成功率：在无需重大人工干预下，能完成闭环（给出被认可的根因和建议）的任务比例。
• 成本 per 任务：平均每个诊断任务消耗的LLM API Token费用和计算资源。

我们通过对比引入Agent协作前后，处理同类线上问题的MTTD，发现平均有约40%的下降，尤其是在信息搜集和初步关联分析环节，节省了大量时间。人工介入率目前还比较高，大约在30%，主要发生在需要复杂业务逻辑判断或执行生产变更的环节。

6.2 常见挑战与应对策略

在实践中，我们遇到了不少挑战，也总结了一些应对策略：

1. “幻觉”与信息误导：LLM可能在分析时编造不存在的证据或建立错误的因果关系。
   • 对策：强化“基于证据”的Prompt设计，要求Analyst的每一个结论性陈述都必须引用工作空间中的具体数据块ID。同时，建立“交叉验证”机制，对于关键结论，可以用不同的Prompt让两个Analyst独立分析，再对比结果。
2. 复杂业务逻辑理解不足：Agent很难理解深层次的、未文档化的业务代码逻辑。
   • 对策：不指望Agent成为业务专家。当问题涉及复杂业务逻辑时，系统应能识别并主动请求人工介入。同时，可以逐步构建业务知识图谱，作为工作空间的静态参考信息提供给Agent。
3. 安全与权限的边界：这是最大的风险点。
   • 对策：严格执行“最小权限原则”。Executor Agent的操作范围必须被沙盒化，仅限预授权的、低风险的、非生产的操作。所有写操作（代码提交、配置修改）必须经过“人类确认”环节。建立完整的操作审计日志，所有Agent的决策、行动都被记录，可追溯。

6.3 未来的演进方向

目前的实践只是一个起点。我们认为有几个值得深入的方向：

• Agent能力的持续垂直化：可以训练或微调专用于代码审查、SQL性能分析、架构异味检测等特定领域的“专家Agent”，替代通用的Analyst，提供更深度的诊断。
• 从诊断到自治修复：在安全可控的前提下，逐步扩大Executor的授权范围，从“回滚”到“应用已知补丁”，再到“根据规则集调整配置参数”，实现更高级别的自治。
• 知识沉淀与复用：将每次成功的诊断案例，包括问题现象、分析路径、根因和解决方案，结构化地存入知识库。未来的Planner Agent在解析新任务时，可以先进行案例检索，实现“经验复用”，甚至实现“从未见过的问题，但能类比历史案例解决”。
• 人机协作界面（UI）的优化：当前主要通过Chatbot交互，未来可以开发一个可视化的工作空间看板，实时展示任务状态、Agent活动、证据链条和数据流向，让人工参与和监控更加直观高效。

这套适合程序员的Agent协作实践，其核心价值不在于追求完全无人值守的“自动化”，而在于构建一个可扩展、可观测、可干预的人机协同系统。它把程序员从信息苦力中解放出来，让我们能更专注于那些真正需要创造力、判断力和深厚技术底蕴的工作。开始实践吧，从一个具体的、高频率的小任务场景入手，你会很快感受到这种范式带来的变化。