AI Agent 多智能体编排架构实战：从PoC到事件驱动的架构演进与踩坑全记录

并红塔2026-07-17 9:41

🎯 目标读者：正在做或即将做 AI Agent 平台的后端架构师、技术负责人。如果你遇到了"单 Agent 扛不住复杂任务"、"Agent 之间状态耦合严重"、"加一个新 Agent 要改一堆代码"这类问题，这篇文章的三版演进经验可以直接复用。

一、背景：从代码审查工具到 Agent 编排平台

2022 年底，我在深信服内部主导了一个单 Agent 代码审查工具------用户提交代码，Agent 调用内部私有化部署的 LLM（基于 vLLM 推理 Qwen2.5-Coder）分析代码质量、给出修改建议。

从立项到上线只花了 3 周。效果超出预期：代码审查建议采纳率 67%，团队内部日活 200+。

然后需求开始膨胀------

"能不能不只审查代码，顺便跑一下单元测试，再生成变更文档？" "安全团队想加一个安全扫描 Agent，怎么接入？" "我们团队想做一个 DBA Agent，能直接审查 SQL 变更吗？"

一个 Agent 干不了多件事。不是 LLM 不行，是架构撑不住：

  1. 单 Agent 上下文爆炸：代码审查 + 测试执行 + 文档生成，Prompt 超过 128K，LLM 开始"遗忘"早期指令
  2. 工具调用串行阻塞：一个 Agent 依次调用多个工具，单次任务 3-5 分钟
  3. 无法复用和扩展：想做"安全扫描 Agent"，发现代码审查 Agent 里的工具调用逻辑全耦合在一起，拆不出来

从 2023 年初到 2024 年中，我经历了三版架构演进。后来在做企业架构咨询的过程中，基于这套实践经验进一步打磨，将其沉淀为一个通用的多 Agent 编排方案。

完整时间线：

阶段 时间 持续 关键产出
V1 PoC 2022.11 - 2022.12 3 周 单 Agent 代码审查工具上线，验证核心假设
V2 工程化 2023.01 - 2023.06 ~6 个月 4 个 Agent 拆分，Orchestrator 编排，上线后 2 次事故
V3 事件驱动 2023.07 - 2024.03 ~9 个月 事件总线 + Context Snapshot + 动态路由，稳定运行
通用化沉淀 2024.04 - 2024.08 ~5 个月 多模型适配、Agent SDK、Docker 一键部署

💡 好的架构不是设计出来的，是从失败中生长出来的。 这篇文章记录的不是一个"完美方案"，而是一条"踩坑---复盘---重构"的真实路径。

这篇文章的核心经验是 ：不要一开始就设计"完美架构"。先用最小成本验证业务可行性，确认有价值后再逐步重构。架构演进的正确节奏是：先验证、再工程化、最后平台化。

二、V1：最小可行 PoC（2周跑通验证）

2.1 设计思路：先验证，后设计

V1 的目标非常明确------用最短时间验证"Agent + LLM + 工具调用"这条技术路线是否可行。

作为一个做了多年后端的人，我太清楚"过度设计"的代价了。在没有真实流量验证之前，任何架构设计都是纸上谈兵。所以 V1 的原则是：

  • 只验证核心假设：LLM 能否可靠地驱动工具调用完成代码审查任务？
  • 刻意不做的事：多 Agent 编排、复杂状态管理、可视化界面
  • 刻意要做的事：基础的工具抽象层、异步执行、错误重试、简单的可观测性

为什么刻意做了工具抽象？因为即使是最简单的 PoC，如果工具调用逻辑直接写在业务代码里，连基本的验证都做不准确------你分不清是 LLM 能力不行，还是你的工具封装有问题。

💡 PoC 的价值不在于代码有多简单，在于你清楚地知道哪些地方是"故意简单"的。 每一行"没写"的代码，都应该是有意为之，而不是能力不足。

2.2 架构设计与核心代码

V1 是一个结构清晰的单 Agent，但核心抽象层是认真设计的：

python 复制代码 
# V1：最小可行 PoC --- 单 Agent + 工具调用循环
class AgentEngine:
    def __init__(self, llm_gateway: LLMGateway, max_iterations: int = 5):
        self.llm = llm_gateway
        self.tool_registry = ToolRegistry()  # 统一工具注册表
        self.max_iterations = max_iterations  # 防止无限循环
        self.token_budget = 8000              # Prompt token 预算

    async def execute(self, task: str) -> AgentResult:
        """ReAct 循环：思考 → 行动 → 观察 → 再思考...直到得出最终答案"""
        messages = self._build_initial_messages(task)
        
        for i in range(self.max_iterations):
            response = await self.llm.chat(
                messages=messages,
                tools=self.tool_registry.get_schemas(),
                max_tokens=self.token_budget,
            )
            if response.has_tool_calls:
                for call in response.tool_calls:
                    result = await self.tool_registry.execute(call.name, call.arguments)
                    messages.append({"role": "tool", "content": result.to_json()})
            else:
                return AgentResult(output=response.content, iterations=i + 1)
        
        return AgentResult(output="[max iterations reached]")

class BaseTool(ABC):
    """工具统一接口------V1 最值得设计的部分，后来直接被 V2/V3 继承"""
    @property
    @abstractmethod
    def name(self) -> str: ...
    
    @abstractmethod
    def schema(self) -> dict:
        """返回 JSON Schema，告诉 LLM 这个工具的参数格式"""
    
    @abstractmethod
    async def execute(self, **kwargs) -> ToolResult: ...

核心代码约 500 行 Python。V1 最值得说的部分是 BaseTool 统一接口------即使是最简单的 PoC，工具调用也不能直接写在业务代码里。这个接口后来直接被 V2/V3 继承，省了大量重构成本。

2.3 PoC 验证结果与天花板

3 周上线，核心假设全部验证通过：

验证项 结果 结论
LLM 能可靠驱动工具调用 工具调用成功率 94% ✅ 技术路线可行
单 Agent 完成代码审查 审查建议采纳率 67% ✅ 业务价值验证通过
团队愿意持续使用 日活稳定 200+ ✅ 用户留存验证通过

但天花板也很快暴露了：

瓶颈 具体表现 严重程度
上下文爆炸 3 个以上工具调用后 Prompt 超 32K tokens，幻觉率飙升 🔴 致命
无法并行 代码分析、测试、文档串行执行，单次 3-5 分钟 🟡 体验差
不可复用 想做"安全扫描 Agent"，发现和代码审查 Agent 完全耦合 🔴 阻塞扩展

教训：什么时候该从 PoC 升级到正式架构？当你开始遇到"架构层面"的问题（上下文爆炸、无法扩展），而不是"功能层面"的问题（少一个功能）时。前者必须重构，后者可以加功能。

三、V2：工程化重构（拆分了 Agent，但没解决核心问题）

3.1 设计思路

PoC 验证通过后，安全团队和测试团队都提出了接入需求。当时有两个选择：一是在 V1 上加功能（快但耦合更重），二是拆分成多 Agent（慢但可扩展）。我倾向于直接做多 Agent，团队里有人反对------"V1 跑得挺好，为什么要重构？"最终说服他的理由是：安全扫描 Agent 需要的工具集和代码审查完全不同，硬塞进同一个 Agent 只会让 Prompt 更长、幻觉更多。

核心变化：

  1. Agent 拆分：不同职责由专门的 Agent 处理，每个 Agent 有独立的 Prompt 和工具集
  2. 编排器：引入 Orchestrator 管理多 Agent 的执行顺序和数据传递
  3. 状态持久化：引入 Redis 存储中间状态，支持断点续跑
  4. 工作流配置化：执行流程从硬编码改为 YAML 配置
python 复制代码 
# V2：串行编排------看起来合理，但设计成了最大的问题根源
class Orchestrator:
    def __init__(self, state_store: RedisStateStore):
        self.agents = {}
        self.pipeline = []           # 写死的执行顺序
        self.state_store = state_store

    async def execute(self, task: str) -> dict:
        results = {}
        context = await self.state_store.load_or_create(task_id=task)

        for step_name in self.pipeline:
            agent = self.agents[step_name]
            # 把完整的 context 传给 Agent（问题根源：context 会无限膨胀）
            result = await agent.execute(context)
            results[step_name] = result
            context[f"{step_name}_result"] = result  # ← 每步追加，到第4步已经炸了
            await self.state_store.save(task_id=task, context=context)

        return results

3.2 解决了部分问题，但引入了更大的问题

Agent 拆分确实解决了上下文爆炸------每个 Agent 的 Prompt 控制在 8K 以内，耗时从 3-5 分钟降到 2 分钟以内。安全团队顺利接入了安全扫描 Agent。

但新的问题正在酝酿。

V2 在 2023 年初上线，跑了大约半年，挂了 4 个 Agent（代码审查、测试执行、文档生成、安全扫描）。期间出过两次印象深刻的事故：一次是 Redis 重启丢了全部共享状态，正在执行的十几个任务全挂了，只能人工重新提交；另一次是 Orchestrator 里一个 2000 行的大方法改了个变量名忘了改另一处，所有 pipeline 全部失败，排查了两个小时才定位到。这两次事故直接推动了 V3 的重构决策。

💡 共享状态是多 Agent 系统的第一大杀手。 它不会在你设计架构的时候爆发，而是在第三个 Agent 上线的某个凌晨三点，以一场线上事故的形式找你算账。

问题 1：Orchestrator 变成了上帝对象。 任务拆解、Agent 调度、结果传递、错误处理、超时控制全挤在一个类里，代码膨胀到 2000+ 行，改一个 Agent 的执行逻辑可能要改 5 个方法。

问题 2：共享状态是定时炸弹。 context[f"{step_name}_result"] = result 让 context 字典无限膨胀------到第 4 步时，DocAgent 收到的 context 里包含了代码审查的原始代码、测试日志、测试报告......Prompt 又炸了，只是换了个地方炸。

问题 3：静态 pipeline 无法应对真实场景。 代码审查发现安全问题需要先跑安全扫描、测试失败需要重新审查------这种分支逻辑在静态 pipeline 里只能 if-else 硬编码，每加一个场景就要改 Orchestrator 核心逻辑。

3.3 为什么不打补丁？

修补方案 为什么放弃
context 瘦身：只传必要字段 每加一个 Agent 就要重新定义"必要字段"，维护成本线性增长
Pipeline 分支：YAML 里加条件 20+ 条条件规则，YAML 比代码还难维护，条件组合爆炸
RPC 直调：Agent A 直接调 Agent B 超过 5 个 Agent 后，N*(N-1) 条调用链路无法维护

结论：V2 的架构模式（共享状态 + 静态编排）从根本上无法支撑 Agent 数量的增长。必须换架构。

3.4 V2 → V3 的迁移：灰度切换，不是大爆炸

不是一夜之间从 V2 切到 V3。具体做法：

  1. 先建事件总线基础设施（2 周）：在 V2 旁边搭 Kafka + Trace，V2 继续跑，但事件同步写一份到 Kafka------不做处理，只验证事件格式和流转是否正确。
  2. 逐个 Agent 迁移（4 周）：每次切一个 Agent 到事件驱动模式。先切最独立的 DocGenerator（只接收输入、产出文档，不和其他 Agent 交互），验证通过后再切 TestExecution、SecurityScan，最后切 CodeReview（最核心、交互最复杂）。
  3. 并行跑 2 周：V2 和 V3 同时运行，新任务走 V3，V2 保留为 fallback。如果 V3 出问题，流量切回 V2。实际没有切回去------V3 上线第一天就跑得比 V2 稳。
  4. 数据迁移：V2 的 Redis 共享状态不迁移（设计上就是临时的），V3 用 Context Snapshot 替代。历史任务的 trace 数据保留在 MySQL，供复盘用。

整个过程 8 周，2 人全职。期间没有中断过线上服务。

四、V3：事件驱动架构（最终方案）

4.1 设计目标

  1. Agent 间零直接依赖------Agent 不认识其他 Agent，只认识事件
  2. 状态隔离------每个 Agent 只看到自己需要的上下文，不接收全量数据
  3. 动态编排------执行路径由事件流决定，不是代码写死
  4. 可观测------每个事件、每次 Agent 调用、每个工具执行都有 trace

💡 事件驱动的本质不是解耦，是让系统的每个决策点都能独立演化。 新增一个 Agent 不需要改动任何其他 Agent 的代码------这是事件驱动在多 Agent 场景下的核心价值。

4.2 架构总览

V3 的核心是一个事件总线（Event Bus），所有 Agent 通过事件总线通信，不直接调用其他 Agent。

四层架构：

层级 职责 核心组件
接入层 请求认证、任务路由、结果聚合 API Gateway, Task Router, Result Collector
Agent 运行时 独立的 Agent 执行环境，状态完全隔离 CodeReview / Test / Doc / Deploy Agent
事件总线 异步事件分发，Agent 间零直接依赖 Event Bus (Publish/Subscribe)
基础设施层 共享存储、工具执行、LLM 推理 State Store(Redis), Tool Sandbox(Docker), LLM Gateway(vLLM)

4.3 核心设计：事件总线 + 上下文隔离

事件总线不只是一个消息队列，而是一个带路由规则的异步事件分发系统 。每个 Agent 事件都携带 correlation_id（同一工作流共享）和 context_snapshot（上下文快照------状态隔离的关键）。

Context Snapshot 隔离 是 V3 最重要的设计，也是 V2 最大的坑的解法。每个 Agent 在处理事件时，只从 context_snapshot 中提取自己需要的上下文，而不是接收全量数据：

关于快照的一致性语义 ：Context Snapshot 采用的是读时快照（Read-time Snapshot） ------事件发送时冻结一份上下文副本，接收方基于这份冻结副本工作。不是强一致性（不锁全局状态），是最终一致性 + 快照隔离的折中：每个 Agent 看到的是"发送时刻的一致视图"，但多个 Agent 并发修改的合并由 Orchestrator 在结果聚合阶段处理。在我们的场景中，大多数 Agent 的工作流是 DAG（无并发写），所以快照隔离足够；只有极少数场景（两个 Agent 同时修改同一文件）需要 Orchestrator 做 merge。

python 复制代码 
class Agent:
    async def execute(self, event: AgentEvent) -> AgentEvent:
        # 1. 只从快照中提取自己需要的上下文（状态隔离的核心）
        relevant_context = self._extract_context(event.context_snapshot)

        # 2. 用局部状态 + 事件上下文构造 Prompt（Prompt 不再爆炸）
        prompt = self.prompt_template.render(
            task=event.payload.get("task"),
            context=relevant_context,  # ← 只有这个 Agent 需要的部分
        )

        # 3. 调用 LLM + 执行工具
        response = await self.llm_gateway.chat(prompt)
        tool_results = await self._execute_tools(response)

        # 4. 构造输出事件------只传递下游 Agent 需要的上下文
        return AgentEvent(
            event_type=EventType.AGENT_COMPLETED,
            source_agent=self.name,
            payload={"result": self._summarize(response, tool_results)},
            correlation_id=event.correlation_id,
            context_snapshot=self._build_downstream_context(
                event.context_snapshot, relevant_context, tool_results
            ),
        )

这个设计一举解决了 V2 的三个问题：

V2 的问题 V3 的解法
context 字典无限膨胀 每个 Agent 只提取自己需要的上下文
Agent 间状态耦合 发送方决定下游能看什么
Prompt 爆炸 每个 Agent 的 Prompt 只包含自己需要的信息

4.4 动态路由引擎

V3 的编排不再是静态 pipeline，而是基于事件路由的条件分支引擎，通过 YAML 配置实现动态分支，不改代码：

yaml 复制代码 
# workflow 定义（YAML 配置，不是硬编码）
name: "code-review-pipeline"
steps:
  - agent: code-review
    on_complete:
      - condition: "result.severity == 'critical'"
        next: security-scan    # 发现安全问题 → 先跑安全扫描
      - condition: "default"
        next: test-execution   # 正常情况 → 直接跑测试

  - agent: test-execution
    on_complete:
      - condition: "result.pass_rate < 0.8"
        next: code-review      # 测试不通过 → 重新审查
      - condition: "default"
        next: doc-generator    # 通过 → 生成文档

诚实说明 ：这里说的"动态"指的是"条件分支动态路由"，本质上还是规则引擎（YAML 里写 if-else），不是 LLM 自主规划的真正动态。我们的场景下，规则引擎够用且可控------每条分支规则都是确定的，线上出了问题好排查。但规则引擎不是终点，关于编排引擎从规则到 LLM 动态编排的演进路线，详见专题文章。

4.5 量化效果

V3 上线 3 周后的实测数据：

技术指标：

指标 V1 单Agent V2 串行编排 V3 事件驱动
单次任务平均耗时 4.2 min 2.8 min 0.9 min
Agent 平均 Prompt 长度 45K tokens 12K tokens 6K tokens
LLM 幻觉率 23% 11% 3%
单 Agent 故障影响范围 全部任务失败 当前 pipeline 失败 仅当前 Agent
新 Agent 接入成本 重写全部逻辑 修改 Orchestrator 只需订阅事件

V3 耗时 0.9min 是关键路径耗时------V2 是严格串行（各步骤之和），V3 中无依赖关系的 Agent 可并行执行（如代码审查和安全扫描同时跑）。

业务影响：

维度 V2 V3 变化
日均处理任务量 120 个 380 个 +217%
研发交付周期 平均 45 min/PR 平均 15 min/PR -67%
LLM 推理成本（月） ¥8,400 ¥3,200 -62%
线上故障恢复时间 平均 30 min 平均 5 min -83%
新 Agent 上线周期 2-3 天 2-3 小时 从人天级到小时级

数据测量方法：LLM 幻觉率从每版上线后第一周随机抽 200 样本，2 名高级工程师独立评审（Kappa 一致性 0.78）；任务耗时取 P50 值；LLM 推理成本按私有化部署 vLLM 的 GPU 服务器使用时长折算（A10 40GB，约 ¥8/h）。

数据来源说明 ：以上数据来自深信服内部开发工具环境（2024 年 Q2-Q3 测量，日均活跃用户约 200），非商用生产环境流量。内部工具的用户群体相对固定、任务模式较为集中，性能数据在同等规模的内部工具场景下具有参考价值，但未经历大规模商用流量的压力测试。

关于投入产出的诚实说明：

如果只算 LLM 推理成本------每月节省 ¥5,200，对比 4 个月 2 人的人力投入，单纯从"推理成本"角度显然收不回。所以不能只算 LLM 的账。

V3 真正的回报在"能力天花板"：吞吐量 3 倍提升、交付周期 -67%、新 Agent 上线从人天到小时级、故障恢复 -83%。

💡 架构升级的价值，往往不在"省了多少钱"，而在"打开了多大的天花板"。

五、关键决策复盘

5.1 为什么选事件驱动而不是 RPC？

方案 优点 缺点
RPC（Agent 直接调用） 简单直接，调试方便 Agent 间强耦合，改一个要改一片
事件驱动（Pub/Sub） 零直接依赖，动态路由 调试链路长，需要 trace 工具

核心考量：Agent 数量会从 4 个增长到 10+ 个，RPC 的 N*(N-1) 条调用链路不可维护，事件驱动把 N*(N-1) 降为 N。

调试成本的真实代价 ：V2 的 RPC 模式下，排查一次跨 Agent 问题平均 20-30 分钟（打断点、看日志、串流程）。V3 事件驱动初期，同样问题的排查时间反而上升到 40-60 分钟------事件异步流转、多个 Agent 各自处理、需要靠 correlation_id 串 trace。引入 OpenTelemetry 之后，常规问题降到 10-15 分钟（直接看 trace 链路），但前期建设 Trace 体系花了 5 人天。这是一个 2-3 周才能回本的投资。

5.2 为什么用 Redis，以及什么时候该升级到 Kafka

初期用 Redis Pub/Sub 是因为团队熟悉、部署简单。但 Redis Pub/Sub 有一个致命缺陷------消息不持久化，编排器重启期间事件直接丢失。

过渡方案：Redis Pub/Sub + MySQL 事件日志表双写兜底，丢了从日志表恢复。跑了两个月后 Agent 增长到 8+，事件量翻倍，最终迁移到 Kafka。

💡 技术选型的正确姿势不是"一步到位"，而是"知道什么时候该升级"。 Redis Pub/Sub 在 4 个 Agent、QPS < 100 时完全够用；当你发现"事件丢失导致的线上问题"频繁出现时，就该换 Kafka 了。

5.3 为什么不用 LangGraph / CrewAI / AutoGen / Temporal？

框架 核心优势 没采用的原因
LangGraph 图编排，支持条件分支和循环 与 LangChain 强绑定；Agent 增长后图结构难以维护
CrewAI 角色分工+协作，上手简单 更适合"讨论协作"场景，对工具调用+沙箱执行支持有限
AutoGen 多 Agent 对话式协作 核心范式是 Agent 对话，不适合"任务拆分→工具执行→结果聚合"流水线
Temporal 成熟的工作流引擎 Signal/Activity 粒度偏粗；运维依赖 Cassandra/MySQL/ES 集群，小团队性价比低

坦率说：如果你的场景是"几个 Agent 围绕一个主题讨论协作"，CrewAI/AutoGen 是更好的起点。如果场景是确定性业务流程，Temporal 是首选。我们的核心需求是"任务拆解 + 工具隔离执行 + 动态路由"，更像一条事件驱动的生产流水线。关于这五个方案的详细评测和选型决策树，我会在后续专题文章中展开。
为什么不在某个框架上做二次开发？ 这是最常被问到的问题。我们确实评估过------LangGraph 的图状态机和事件驱动的消息模型差异太大，硬套 LangGraph 等于重写一半；CrewAI 的 Agent 对话范式和我们的"任务流水线"范式不匹配，改框架本身的成本不亚于从头写；Temporal 倒是可以，但它的运维栈（Cassandra/ES/MySQL 三件套）对我们 2 人团队来说太重了。最终结论：Build 的 14 人天 vs 二次开发的 7-10 人天（还得忍受框架约束），选 Build 是因为长期维护成本更低。
💡 没有银弹，只有权衡。 每个架构决策都是在用复杂度换能力------你选择了事件驱动的灵活性，就要接受调试链路变长的代价。

5.4 什么场景不该用事件驱动？

场景 为什么不适合 更好的选择
Agent 数量 < 3 事件驱动的复杂性成本远超收益 简单函数调用或 pipeline
强一致性要求 事件驱动是最终一致性的 Temporal / Saga 模式
低延迟（< 100ms） 异步开销不可忽视 RPC 直调 + 共享内存
无可观测性基础设施 没有 trace 工具，调试会变成噩梦 先用同步架构，同时建设可观测性

5.5 组织维度：架构演进不只是技术问题

V2 → V3 的切换不仅仅是代码重构，还涉及团队技能转型（事件驱动范式、异步调试）、调试流程重建（从"打断点"到"看 trace"）、故障响应机制和文档体系。我们花了 2 周做内部分享 + pair programming 来完成这个转型。

💡 技术架构可以一夜之间切换，但团队的认知和习惯不能。 如果你忽略了"人"的维度，再好的架构也会在团队手里退化。

六、从内部工具到通用方案

这套架构最初是深信服内部的技术探索项目。离开深信服后，我在做企业架构咨询的过程中，基于这套实践经验服务了多个客户的 AI Agent 平台需求：

改造点 内部版 通用版
LLM 接入 内部 vLLM 私有化部署 多模型适配层（vLLM / OpenAI API / 本地模型）
Agent 定义 硬编码 4 个 Agent Agent SDK，自定义 Agent 热插拔
部署方式 K8s 内部集群 Docker Compose 一键部署
事件总线 Redis Pub/Sub 支持 Redis / Kafka / RabbitMQ 可切换

框架的核心不是功能多强大，而是让使用者能多快地跑通自己的第一个工作流。

关于代码：AgentForge 的核心模块（事件总线、编排引擎、Trust Boundary、AIMD 拥塞控制器）约 4,000 行 Python，目前作为个人咨询参考项目维护，暂未开源。博客中的代码示例是经过精简的教学版本（每个 50-100 行），保留了核心设计思路，去掉了错误处理、日志、配置等工程细节。如果你对这些模块的完整实现感兴趣，可以联系我交流。

七、写在最后

回头看这三版架构的演进，最大的收获不是某个具体的技术方案，而是几个底层认知：

第一，架构是长出来的，不是画出来的。 没有人在白板前面就能画出正确的架构。好的架构一定是从 PoC 的失败里、从线上事故的教训里、从团队的抱怨里慢慢长出来的。

第二，先验证再重构，这个节奏不能乱。 V1 不是"做得烂"，是"故意简单"。V2 也不是"设计失误"，是在当时的认知和资源约束下的最优解。每一版架构都有它的历史使命。

第三，没有银弹，只有权衡。 事件驱动不是万能的。它解决了耦合问题，带来了调试复杂度。它解决了扩展问题，带来了运维复杂度。每一个架构决策都是在用一种复杂度换另一种复杂度，关键是这个交换是否值得。

后续专题文章：

如果你也在做 Agent 编排相关的工作，欢迎在评论区聊聊你遇到的问题，我会逐条回复。

作者：彭黎，8年后端研发，3年团队管理，专注 AI Agent 架构方向。 🔗 个人博客：pengli-ctrl.github.io/blog | GitHub：github.com/pengli-ctrl

相关推荐
小马过河R1 小时前
微前端实践：从概念、原理到 qiankun 落地
前端·人工智能·前端框架
Cloudtechnology1 小时前
GEO服务商哪家好？2026年头部服务商技术路线、行业适配与ROI数据全解析
大数据·人工智能
集之互动1 小时前
坚守合规传播底线 集之互动AI TVC重构大健康品牌精细化传播体系
人工智能·重构
动物园猫1 小时前
钢材表面缺陷目标检测数据集：6类别 | 目标检测
人工智能·目标检测·计算机视觉
zyplayer-doc1 小时前
企业文档的进化：网盘和在线文档的下一个升级方向—知识库系统
java·大数据·数据库·人工智能·ocr
Kobebryant-Manba1 小时前
Bert预训练数据&代码
人工智能·深度学习·bert
geneculture1 小时前
基于融智学范畴论、双重形式化与中文屋解密的第二代计算范式
大数据·人工智能·智慧系统·融智学的重要应用·融智时代（杂志）
guo_xiao_xiao_1 小时前
YOLOv11马匹皮肤病目标检测数据集
人工智能·yolo·目标检测
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03AI科技热点日报 | 2026年07月01日04幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南05AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路06国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08Codex 下载安装指南：Windows 和 macOS 官方版下载092026 年 AI 大模型 & AI 编程工具实战全总结10全面体验 Grok API 中转站（2025 · Grok 4 系列最新版）