Agent 开发架构从增强型 LLM 到可运维的自治系统过去一年里Agent 从一个容易被营销滥用的词逐渐沉淀成一套工程问题如何让大模型在明确边界内感知上下文、选择工具、执行动作、接收反馈并在失败时恢复真正困难的地方往往不在“让模型说得像人”而在把模型放进一个可测试、可观测、可控的运行系统里。本文把 Agent 开发架构拆成几个层次基础定义、核心组件、编排模式、多 Agent 取舍、上下文与工具协议、安全治理以及一套可落地的参考架构。1. 先定义Workflow 和 Agent 不是一回事在工程实践中建议把“Agentic system”分成两类Workflow由代码预先规定路径大模型和工具只是其中的节点。例如“先抽取字段再校验再生成报告”。Agent模型动态决定下一步做什么、调用哪些工具、何时停止。例如“修复一个未知代码仓库里的 bug”它需要不断观察测试结果、搜索文件、修改代码并重试。Anthropic 在《Building effective agents》中给出的经验很值得作为架构原则从最简单方案开始只有当任务确实需要弹性决策、多步反馈或开放式探索时才引入 Agent。原因很朴素Agent 会用更多模型调用、更多工具执行和更复杂状态成本、延迟、调试难度都会上升。一个实用判断标准是如果任务路径稳定、输入类型清晰优先用 workflow。如果任务步骤不可预知、需要模型根据环境反馈调整策略再考虑 agent。如果单次 LLM RAG 示例就能解决不要为了“架构感”强行上 Agent。2. Agent 的核心组件一个生产级 Agent 通常不是“一个 prompt”而是以下组件的组合。2.1 模型与指令层模型负责推理、规划、生成结构化参数。指令层定义角色、任务边界、输出格式、停止条件和工具使用规则。越接近生产指令越应该像接口契约而不是散文。建议把系统指令分成四类身份与目标这个 Agent 负责什么不负责什么。决策策略什么时候调用工具什么时候询问用户什么时候拒绝。输出契约返回 JSON、Markdown、代码补丁还是用户消息。约束条件权限、预算、最大迭代轮次、安全边界。2.2 工具层工具是 Agent 与外部世界连接的手。工具可以是函数、HTTP API、数据库查询、浏览器、文件系统、代码执行器、搜索引擎或企业内部工作流。工具设计是 Agent 架构中最容易被低估的部分。一个好工具应该具备清晰的名称和职责不要一个工具塞进太多动作。明确的输入 schema 和输出 schema。可恢复的错误信息而不是只返回“失败”。幂等性或事务边界尤其是涉及付款、删除、发邮件、改生产数据时。权限分级高风险工具默认需要确认。OpenAI Agents SDK 把 function tools、MCP server tool calling、guardrails、sessions、handoffs、tracing 都放进同一个运行模型里这反映了一个趋势工具不再只是“函数调用”而是 Agent runtime 的核心边界。2.3 上下文与记忆层Agent 的质量很大程度上取决于它“看见了什么”。上下文通常包括当前用户输入。对话历史。检索到的文档、代码、数据。工具调用结果。中长期记忆如用户偏好、项目约束、历史决策。当前任务状态如计划、待办、失败原因、已尝试路径。上下文不是越多越好。LangChain 的多 Agent 文档强调了“context engineering”决定每个 Agent 看到哪些信息。上下文过多会增加成本、稀释注意力还可能把无关信息变成错误决策依据。生产系统里常见的上下文策略包括短期状态保存在 session 或 run state 中用于当前任务。长期记忆进入数据库、向量库或用户画像系统需要写入过滤和隐私治理。检索增强按需查询知识库、代码库、业务数据。摘要压缩长任务中把历史步骤压成可追踪摘要。隔离上下文多 Agent 架构中让子 Agent 只拿到完成任务所需的信息。2.4 编排与运行时Agent runtime 负责循环执行接收目标和上下文。调用模型生成下一步决策。校验工具参数和权限。执行工具。把观察结果写回状态。判断继续、暂停、请求人工输入或结束。这看似简单但生产级 runtime 还要处理超时、重试、取消、并发、限流、成本预算、状态持久化、日志、trace、回放和恢复。Google ADK、OpenAI Agents SDK 等框架都在把这些能力标准化Agent 不只是模型调用而是一个可运行、可调试、可部署的长生命周期任务。3. 常见编排模式不要一上来就多 Agent。大多数系统可以从以下模式逐步演进。3.1 Prompt Chaining提示链把任务拆成固定步骤每一步的输出作为下一步输入。例如提取需求。生成方案。校验方案。输出最终文档。适合路径稳定、每步目标清晰的任务。优点是可控、易调试缺点是弹性不足。3.2 Routing路由先判断输入类型再交给不同流程或专用 Agent。例如客服系统把问题分到退款、物流、技术支持、投诉升级。适合输入类别明显、不同类别需要不同工具和策略的场景。路由可以用传统分类器也可以用小模型完成。3.3 Parallelization并行化把任务拆成可并行子任务最后聚合结果。例如安全审查中让多个检查器分别看权限、注入、依赖漏洞和日志泄露。适合需要多视角、可独立计算、对延迟敏感的任务。注意聚合器必须有明确评价标准否则只是把多个不确定答案拼在一起。3.4 Orchestrator-Workers编排器-工作器一个中心编排器动态拆解任务分配给多个 worker再综合结果。它适合子任务数量和类型难以预先写死的场景比如代码修改、复杂研究、跨系统排障。这种模式的关键是编排器要有足够强的任务分解能力worker 要有清晰职责最终合成要能追溯每个结论来自哪里。3.5 Evaluator-Optimizer评价-优化循环一个模型生成结果另一个模型或规则系统评价并提出修改意见循环直到达标或触发停止条件。适合有明确质量标准的任务如翻译润色、代码审查、研究报告、测试生成。它的价值不在“多调用几次”而在评价标准是否可验证。4. 多 Agent 架构什么时候值得用多 Agent 的吸引力很强但它也会带来更多延迟、成本和状态复杂度。一般只有在以下情况值得引入单个 Agent 工具太多容易选错工具。不同领域需要不同上下文和专用能力。任务天然可并行。不同团队需要独立维护不同能力边界。需要角色隔离例如执行者、审查者、审批者分离。常见多 Agent 模式包括Subagents主 Agent 把子 Agent 当工具调用集中控制强上下文隔离好。HandoffsAgent 之间转交控制权适合多轮对话中用户直接和不同专家交互。Router先分类再调用一个或多个专用 Agent适合多领域并行任务。Skills单 Agent 保持控制只在需要时加载专用知识、流程或工具说明。Custom Graph Workflow用图结构显式描述状态流转把确定性逻辑和模型决策混合起来。一个很实用的经验是如果只是想复用知识优先考虑 skills 或工具如果需要并行和上下文隔离再考虑 subagents/router如果用户需要与不同专家连续交互再考虑 handoffs。5. MCPAgent 工具生态的标准化接口Model Context ProtocolMCP试图解决一个核心问题每个 Agent 都要接数据库、文件、SaaS、搜索、企业 API如果每个宿主应用都重复做一套集成生态会非常碎。MCP 使用标准协议把 AI 应用和外部系统连接起来。官方规范中MCP 把通信参与者分为Host发起连接的 LLM 应用。ClientHost 内部的连接器。Server提供上下文和能力的外部服务。Server 可以暴露三类能力Resources可读取的数据和上下文。Prompts可复用的模板消息或工作流。Tools可由模型调用的函数或动作。对 Agent 架构来说MCP 的意义不是“换一种 RPC”而是把工具、数据和提示模板变成可组合、可发现、可治理的边界。未来企业内部很可能会出现一批标准 MCP server代码库、工单系统、CRM、数据仓库、BI、权限系统、文档库等。但 MCP 也会放大安全问题。规范明确提醒工具可能代表任意代码执行路径数据访问和工具调用必须有用户授权、权限控制和清晰 UI。6. 安全、治理与人类介入Agent 的风险来自“会行动”。一个普通聊天机器人说错话影响通常停留在信息层一个接入邮箱、支付、生产数据库和部署系统的 Agent 出错影响会进入真实世界。生产架构中至少要有以下防线输入防护识别 prompt injection、越权请求、恶意文件和不可信网页内容。工具权限按工具、资源、用户、环境划分权限。动作确认高风险动作必须 human-in-the-loop。输出校验结构化 schema 校验、业务规则校验、安全策略校验。沙箱执行代码、浏览器、文件操作尽量在隔离环境中运行。审计日志记录模型决策、工具调用、参数、结果、人工确认。停止条件最大轮次、预算上限、失败次数、时间限制。Human-in-the-loop 不是“让人兜底”这么简单而是要设计清楚哪些节点需要人工判断目标确认、权限授权、不可逆操作、低置信度结果、策略冲突、外部副作用。7. 可观测性与评估Agent 系统不能只看最终回答。它的可观测性至少要覆盖每一次模型调用的输入、输出、token、耗时、成本。每一次工具调用的参数、返回值、错误、重试。当前计划、状态迁移和停止原因。检索命中文档和引用来源。guardrail 是否触发。人工介入点和审批结果。评估也要从“答案是否好看”转向“任务是否可靠完成”。建议建立四类 eval离线样例集覆盖典型输入、边界输入和攻击输入。工具调用正确性是否选对工具、参数是否正确、是否遵守权限。端到端任务成功率如工单解决、代码测试通过、报告可审计。回归评估prompt、模型、工具 schema 改动后是否破坏旧能力。如果你的 Agent 能重放一次失败任务并清楚看到它在哪一步误判那么这个系统才真正进入可工程化阶段。8. 一套参考架构下面是一套面向生产的通用 Agent 架构可按场景裁剪。是否用户 / 上游系统Agent API / 会话入口权限与策略层Agent Runtime上下文管理器模型决策 / Planner短期状态 / 长期记忆 / RAG输入与计划校验工具注册表MCP Servers / 内部 API / 数据库 / 浏览器 / 代码沙箱环境观察结果输出校验 / 风险判断需要人工确认?审批 / 补充信息最终结果 / 产物Tracing / Logs / Metrics / Eval这套架构的核心思想是模型只负责智能决策不直接拥有无限权限工具、上下文、权限、评估、审计都在 runtime 周围形成工程边界。9. 落地路线图阶段一增强型 LLM先做一个单模型应用接入 RAG、少量工具、结构化输出和基本日志。目标是验证任务是否真的需要多步行动。交付物清晰系统 prompt。2-5 个高价值工具。一组离线测试样例。基础 trace 和成本统计。阶段二受控 Workflow把稳定路径固化为 workflow例如“分类 - 检索 - 生成 - 校验 - 输出”。在关键节点加入规则校验和人工确认。交付物状态机或 DAG。中间结果 schema。每一步可单独测试。失败重试和降级策略。阶段三单 Agent Loop当任务步骤不可预知时引入 Agent loop让模型根据观察结果决定下一步。此时必须加入最大轮次、预算、工具权限和停止条件。交付物Agent runtime。工具调用审计。session/state 持久化。高风险动作确认。阶段四多 Agent 或图工作流只有在上下文隔离、并行执行或团队边界确实需要时再引入多 Agent。优先显式建模任务图不要让 Agent 之间自由聊天到失控。交付物主 Agent 与子 Agent 职责边界。上下文传递规则。跨 Agent trace。端到端 eval。10. 常见反模式为了 Agent 而 Agent固定流程硬做成自治循环成本变高且更难调试。工具过大一个工具既查询又写入又发送通知模型一旦选错影响巨大。上下文全塞进去模型被无关内容淹没成本和误判同时上升。没有停止条件失败时无限重试烧钱还可能造成副作用。缺少回放能力线上出错后只能猜 prompt 哪里坏了。把安全交给 prompt仅靠一句“不要做危险操作”是不够的。过早多 Agent多个 Agent 互相转述错误和 token 一起膨胀。结语Agent 架构的本质不是“让模型更自由”而是给模型一套可靠的行动系统它知道目标能看见必要上下文能调用被良好设计的工具能从环境反馈中修正路线也能在风险升高时停下来请求人类判断。最稳妥的路线是从简单开始增强型 LLM、受控 workflow、单 Agent loop再到多 Agent 和图工作流。每引入一层复杂度都应该换来可测量的任务成功率提升而不是只换来一张更漂亮的架构图。参考资料Anthropic Engineering: Building effective agentsOpenAI: OpenAI Agents SDKGoogle: Agent Development Kit documentationLangChain Docs: Multi-agent systemsModel Context Protocol: What is MCP?Model Context Protocol: Specification 2025-06-18arXiv: Large Language Model based Multi-Agents: A Survey of Progress and ChallengesarXiv: A Survey on the Memory Mechanism of Large Language Model based AgentsarXiv: A Survey on Autonomy-Induced Security Risks in Large Model-Based Agents
Agent 开发架构：从增强型 LLM 到可运维的自治系统
发布时间：2026/6/15 2:23:59
Agent 开发架构从增强型 LLM 到可运维的自治系统过去一年里Agent 从一个容易被营销滥用的词逐渐沉淀成一套工程问题如何让大模型在明确边界内感知上下文、选择工具、执行动作、接收反馈并在失败时恢复真正困难的地方往往不在“让模型说得像人”而在把模型放进一个可测试、可观测、可控的运行系统里。本文把 Agent 开发架构拆成几个层次基础定义、核心组件、编排模式、多 Agent 取舍、上下文与工具协议、安全治理以及一套可落地的参考架构。1. 先定义Workflow 和 Agent 不是一回事在工程实践中建议把“Agentic system”分成两类Workflow由代码预先规定路径大模型和工具只是其中的节点。例如“先抽取字段再校验再生成报告”。Agent模型动态决定下一步做什么、调用哪些工具、何时停止。例如“修复一个未知代码仓库里的 bug”它需要不断观察测试结果、搜索文件、修改代码并重试。Anthropic 在《Building effective agents》中给出的经验很值得作为架构原则从最简单方案开始只有当任务确实需要弹性决策、多步反馈或开放式探索时才引入 Agent。原因很朴素Agent 会用更多模型调用、更多工具执行和更复杂状态成本、延迟、调试难度都会上升。一个实用判断标准是如果任务路径稳定、输入类型清晰优先用 workflow。如果任务步骤不可预知、需要模型根据环境反馈调整策略再考虑 agent。如果单次 LLM RAG 示例就能解决不要为了“架构感”强行上 Agent。2. Agent 的核心组件一个生产级 Agent 通常不是“一个 prompt”而是以下组件的组合。2.1 模型与指令层模型负责推理、规划、生成结构化参数。指令层定义角色、任务边界、输出格式、停止条件和工具使用规则。越接近生产指令越应该像接口契约而不是散文。建议把系统指令分成四类身份与目标这个 Agent 负责什么不负责什么。决策策略什么时候调用工具什么时候询问用户什么时候拒绝。输出契约返回 JSON、Markdown、代码补丁还是用户消息。约束条件权限、预算、最大迭代轮次、安全边界。2.2 工具层工具是 Agent 与外部世界连接的手。工具可以是函数、HTTP API、数据库查询、浏览器、文件系统、代码执行器、搜索引擎或企业内部工作流。工具设计是 Agent 架构中最容易被低估的部分。一个好工具应该具备清晰的名称和职责不要一个工具塞进太多动作。明确的输入 schema 和输出 schema。可恢复的错误信息而不是只返回“失败”。幂等性或事务边界尤其是涉及付款、删除、发邮件、改生产数据时。权限分级高风险工具默认需要确认。OpenAI Agents SDK 把 function tools、MCP server tool calling、guardrails、sessions、handoffs、tracing 都放进同一个运行模型里这反映了一个趋势工具不再只是“函数调用”而是 Agent runtime 的核心边界。2.3 上下文与记忆层Agent 的质量很大程度上取决于它“看见了什么”。上下文通常包括当前用户输入。对话历史。检索到的文档、代码、数据。工具调用结果。中长期记忆如用户偏好、项目约束、历史决策。当前任务状态如计划、待办、失败原因、已尝试路径。上下文不是越多越好。LangChain 的多 Agent 文档强调了“context engineering”决定每个 Agent 看到哪些信息。上下文过多会增加成本、稀释注意力还可能把无关信息变成错误决策依据。生产系统里常见的上下文策略包括短期状态保存在 session 或 run state 中用于当前任务。长期记忆进入数据库、向量库或用户画像系统需要写入过滤和隐私治理。检索增强按需查询知识库、代码库、业务数据。摘要压缩长任务中把历史步骤压成可追踪摘要。隔离上下文多 Agent 架构中让子 Agent 只拿到完成任务所需的信息。2.4 编排与运行时Agent runtime 负责循环执行接收目标和上下文。调用模型生成下一步决策。校验工具参数和权限。执行工具。把观察结果写回状态。判断继续、暂停、请求人工输入或结束。这看似简单但生产级 runtime 还要处理超时、重试、取消、并发、限流、成本预算、状态持久化、日志、trace、回放和恢复。Google ADK、OpenAI Agents SDK 等框架都在把这些能力标准化Agent 不只是模型调用而是一个可运行、可调试、可部署的长生命周期任务。3. 常见编排模式不要一上来就多 Agent。大多数系统可以从以下模式逐步演进。3.1 Prompt Chaining提示链把任务拆成固定步骤每一步的输出作为下一步输入。例如提取需求。生成方案。校验方案。输出最终文档。适合路径稳定、每步目标清晰的任务。优点是可控、易调试缺点是弹性不足。3.2 Routing路由先判断输入类型再交给不同流程或专用 Agent。例如客服系统把问题分到退款、物流、技术支持、投诉升级。适合输入类别明显、不同类别需要不同工具和策略的场景。路由可以用传统分类器也可以用小模型完成。3.3 Parallelization并行化把任务拆成可并行子任务最后聚合结果。例如安全审查中让多个检查器分别看权限、注入、依赖漏洞和日志泄露。适合需要多视角、可独立计算、对延迟敏感的任务。注意聚合器必须有明确评价标准否则只是把多个不确定答案拼在一起。3.4 Orchestrator-Workers编排器-工作器一个中心编排器动态拆解任务分配给多个 worker再综合结果。它适合子任务数量和类型难以预先写死的场景比如代码修改、复杂研究、跨系统排障。这种模式的关键是编排器要有足够强的任务分解能力worker 要有清晰职责最终合成要能追溯每个结论来自哪里。3.5 Evaluator-Optimizer评价-优化循环一个模型生成结果另一个模型或规则系统评价并提出修改意见循环直到达标或触发停止条件。适合有明确质量标准的任务如翻译润色、代码审查、研究报告、测试生成。它的价值不在“多调用几次”而在评价标准是否可验证。4. 多 Agent 架构什么时候值得用多 Agent 的吸引力很强但它也会带来更多延迟、成本和状态复杂度。一般只有在以下情况值得引入单个 Agent 工具太多容易选错工具。不同领域需要不同上下文和专用能力。任务天然可并行。不同团队需要独立维护不同能力边界。需要角色隔离例如执行者、审查者、审批者分离。常见多 Agent 模式包括Subagents主 Agent 把子 Agent 当工具调用集中控制强上下文隔离好。HandoffsAgent 之间转交控制权适合多轮对话中用户直接和不同专家交互。Router先分类再调用一个或多个专用 Agent适合多领域并行任务。Skills单 Agent 保持控制只在需要时加载专用知识、流程或工具说明。Custom Graph Workflow用图结构显式描述状态流转把确定性逻辑和模型决策混合起来。一个很实用的经验是如果只是想复用知识优先考虑 skills 或工具如果需要并行和上下文隔离再考虑 subagents/router如果用户需要与不同专家连续交互再考虑 handoffs。5. MCPAgent 工具生态的标准化接口Model Context ProtocolMCP试图解决一个核心问题每个 Agent 都要接数据库、文件、SaaS、搜索、企业 API如果每个宿主应用都重复做一套集成生态会非常碎。MCP 使用标准协议把 AI 应用和外部系统连接起来。官方规范中MCP 把通信参与者分为Host发起连接的 LLM 应用。ClientHost 内部的连接器。Server提供上下文和能力的外部服务。Server 可以暴露三类能力Resources可读取的数据和上下文。Prompts可复用的模板消息或工作流。Tools可由模型调用的函数或动作。对 Agent 架构来说MCP 的意义不是“换一种 RPC”而是把工具、数据和提示模板变成可组合、可发现、可治理的边界。未来企业内部很可能会出现一批标准 MCP server代码库、工单系统、CRM、数据仓库、BI、权限系统、文档库等。但 MCP 也会放大安全问题。规范明确提醒工具可能代表任意代码执行路径数据访问和工具调用必须有用户授权、权限控制和清晰 UI。6. 安全、治理与人类介入Agent 的风险来自“会行动”。一个普通聊天机器人说错话影响通常停留在信息层一个接入邮箱、支付、生产数据库和部署系统的 Agent 出错影响会进入真实世界。生产架构中至少要有以下防线输入防护识别 prompt injection、越权请求、恶意文件和不可信网页内容。工具权限按工具、资源、用户、环境划分权限。动作确认高风险动作必须 human-in-the-loop。输出校验结构化 schema 校验、业务规则校验、安全策略校验。沙箱执行代码、浏览器、文件操作尽量在隔离环境中运行。审计日志记录模型决策、工具调用、参数、结果、人工确认。停止条件最大轮次、预算上限、失败次数、时间限制。Human-in-the-loop 不是“让人兜底”这么简单而是要设计清楚哪些节点需要人工判断目标确认、权限授权、不可逆操作、低置信度结果、策略冲突、外部副作用。7. 可观测性与评估Agent 系统不能只看最终回答。它的可观测性至少要覆盖每一次模型调用的输入、输出、token、耗时、成本。每一次工具调用的参数、返回值、错误、重试。当前计划、状态迁移和停止原因。检索命中文档和引用来源。guardrail 是否触发。人工介入点和审批结果。评估也要从“答案是否好看”转向“任务是否可靠完成”。建议建立四类 eval离线样例集覆盖典型输入、边界输入和攻击输入。工具调用正确性是否选对工具、参数是否正确、是否遵守权限。端到端任务成功率如工单解决、代码测试通过、报告可审计。回归评估prompt、模型、工具 schema 改动后是否破坏旧能力。如果你的 Agent 能重放一次失败任务并清楚看到它在哪一步误判那么这个系统才真正进入可工程化阶段。8. 一套参考架构下面是一套面向生产的通用 Agent 架构可按场景裁剪。是否用户 / 上游系统Agent API / 会话入口权限与策略层Agent Runtime上下文管理器模型决策 / Planner短期状态 / 长期记忆 / RAG输入与计划校验工具注册表MCP Servers / 内部 API / 数据库 / 浏览器 / 代码沙箱环境观察结果输出校验 / 风险判断需要人工确认?审批 / 补充信息最终结果 / 产物Tracing / Logs / Metrics / Eval这套架构的核心思想是模型只负责智能决策不直接拥有无限权限工具、上下文、权限、评估、审计都在 runtime 周围形成工程边界。9. 落地路线图阶段一增强型 LLM先做一个单模型应用接入 RAG、少量工具、结构化输出和基本日志。目标是验证任务是否真的需要多步行动。交付物清晰系统 prompt。2-5 个高价值工具。一组离线测试样例。基础 trace 和成本统计。阶段二受控 Workflow把稳定路径固化为 workflow例如“分类 - 检索 - 生成 - 校验 - 输出”。在关键节点加入规则校验和人工确认。交付物状态机或 DAG。中间结果 schema。每一步可单独测试。失败重试和降级策略。阶段三单 Agent Loop当任务步骤不可预知时引入 Agent loop让模型根据观察结果决定下一步。此时必须加入最大轮次、预算、工具权限和停止条件。交付物Agent runtime。工具调用审计。session/state 持久化。高风险动作确认。阶段四多 Agent 或图工作流只有在上下文隔离、并行执行或团队边界确实需要时再引入多 Agent。优先显式建模任务图不要让 Agent 之间自由聊天到失控。交付物主 Agent 与子 Agent 职责边界。上下文传递规则。跨 Agent trace。端到端 eval。10. 常见反模式为了 Agent 而 Agent固定流程硬做成自治循环成本变高且更难调试。工具过大一个工具既查询又写入又发送通知模型一旦选错影响巨大。上下文全塞进去模型被无关内容淹没成本和误判同时上升。没有停止条件失败时无限重试烧钱还可能造成副作用。缺少回放能力线上出错后只能猜 prompt 哪里坏了。把安全交给 prompt仅靠一句“不要做危险操作”是不够的。过早多 Agent多个 Agent 互相转述错误和 token 一起膨胀。结语Agent 架构的本质不是“让模型更自由”而是给模型一套可靠的行动系统它知道目标能看见必要上下文能调用被良好设计的工具能从环境反馈中修正路线也能在风险升高时停下来请求人类判断。最稳妥的路线是从简单开始增强型 LLM、受控 workflow、单 Agent loop再到多 Agent 和图工作流。每引入一层复杂度都应该换来可测量的任务成功率提升而不是只换来一张更漂亮的架构图。参考资料Anthropic Engineering: Building effective agentsOpenAI: OpenAI Agents SDKGoogle: Agent Development Kit documentationLangChain Docs: Multi-agent systemsModel Context Protocol: What is MCP?Model Context Protocol: Specification 2025-06-18arXiv: Large Language Model based Multi-Agents: A Survey of Progress and ChallengesarXiv: A Survey on the Memory Mechanism of Large Language Model based AgentsarXiv: A Survey on Autonomy-Induced Security Risks in Large Model-Based Agents
![[电子书]马伯庸作品合集（套装23册）](http://pic.xiahunao.cn/yaotu/[电子书]马伯庸作品合集（套装23册）)
