通用智能体的应用和最佳实践

如今，开发者普遍已能借助 Codex、Claude Code、Cursor 这类编程助手来写代码。但写代码只是第一步，业务侧的需求会不断加码——比如自动抓取券商研报并做对比，这类实践已有不少人尝试；而让客服系统真正理解客户意图，难度又上了一个台阶。更进一步，有人已经把从数据采集到报告生成的整条流水线做成了无人值守的自动化流程，基于目标驱动的业务也随之升级。

然而，工具迭代非常快，今天学熟的产品，明天可能就换了新面孔。与其疲于追逐具体工具，不如先建立一套稳定的判断框架。拿到一个业务场景后，关键要回答两个问题：为什么选单 Agent 而非多 Agent？凭什么判断这个方案能真正跑通？有了这个底层逻辑，才能应对持续变化的技术选型。

我认为 Agent 构建的基本原则是场景决定架构，架构决定工具。 先定场景，架构随之成型；架构定了，工具的匹配会顺理成章。

正本清源，智能体是什么

市面上名词很多，Agent、Skills、Tools、Agent Harness，还有 Harness Engineering、Loop Engineering、Graph Engineering，越堆越晕。按词条背定义更是不知所谓。追根溯源，我们先看一套 LLM Agent 实际怎么跑。下面这条闭环是通用智能体运行时的常见骨架。它把概念嵌进机制里理解更加容易。

四步闭环构成 Agent 系统

一次完整的任务执行，通常沿着下面四个步骤走完一轮。

1. 1. 汇聚上下文 工作记忆区会先收集当前可用的全部信息：用户输入、系统提示词（常见放在 SOUL.md 中），再加上长期记忆、知识库和会话历史等注入内容。模型在这一刻能看到的所有东西，都在这个集合里。
2. 2. 核心推理 LLM 读取工作记忆后，开始分析任务并规划行动。Anthropic 认为，智能体是一个能自主决定操作流程、调用工具以实现目标的系统；而 OpenAI 则给出了更直观的公式：Agent = 模型 + 指令 + 工具 + 运行时/记忆。两家视角不同，说法自然有差异。综合来看，我们可以这样定义：Agent 是一整套闭环系统，其中 LLM 充当大脑，记忆和规划模块围绕在侧，工具库随时待命。
3. 3. 决策与执行 模型会根据当前状态判断是否需要调用工具。如果需要，就执行对应动作（如搜索网页、读取文件、调用 API、运行代码等），把结果写回循环，继续下一步推理；如果不需要，则直接生成最终输出或产生副作用。这里调用的每个原子能力，通常只做一件具体的事。
4. 4. 状态持久化 最终输出会被写回情景记忆，并跨会话持续跟踪。如果没有这一步，下一轮对话就得从零开始。

支撑这四步稳定运转的，是 Agent Harness——它负责把循环、记忆和工具接入统一管理，提供标准可靠的运行环境，让开发者不必每次都从头搭建。模型之外的那些“脚手架”（会话与记忆管理、工具接入、权限与沙箱、循环控制、日志与可观测性）都归属于 Harness。无论是专用的编码 Agent，还是通用操作系统型 Agent，底层都依赖某种 Harness，区别仅在于它针对哪种场景做了优化。

三层记忆，各管一摊

Agent 的持续运转，依赖三层记忆的分工配合。

程序性记忆，对应 SKILL.md，也就是常说的 Skills。它按需加载，存放行动指南、操作指令和脚本，把固定流程和领域经验固化下来，方便 Agent 随时调用。Skills 是 Agent 的核心组成部件。 业内比较稳的做法是：Tool 只管“能做什么动作”，Skill 负责“按什么顺序把动作串起来”——它往往编排多个 Tools，同时带上领域指令、检查清单或输出格式。很多人容易混淆，只因粒度不同：有人把“调用搜索”也叫 Skill，有人只把“写完整研报的整套流程”才算 Skill。理解这点就好。

语义记忆，对应 MEMORY.md 和知识库，通过 RAG 向量检索，存放长期事实和用户画像。

情景记忆，对应会话记录和数据库，通过 SQL 等方式查询带有时间戳的历史事件。前面第四步写回的输出，主要就落在这里。

三个工程方向：Harness、Loop、Graph

近来常听到 Loop Engineering、Graph Engineering、Harness Engineering 这几个词，虽然还没有统一的标准定义，但按主流理解可以这样看：。

Loop Engineering：设计循环的节奏和终止条件——什么时候观察，什么时候重新规划，什么时候收工。 Graph Engineering：把控制流显式化为图或状态机，节点是步骤或角色，边是转移条件，方便审阅、回放和失败回退。

Harness Engineering：搭建模型之外的运行时底座，管理工具权限、记忆会话、沙箱环境、可观测性、失败重试等。

三者往往叠加使用：图来刻画流程，循环决定推进节奏，Harness 保证整套机制跑得稳。

通用智能体与专用智能体

专用智能体里最典型的是编码类 Agent（如 Claude Code、Codex、Pi），专攻写代码。

通用智能体则完全是另一回事，比如 Hermes、OpenClaw 这类——它们更像是围绕大模型构建、能长期托管多种任务的操作系统。

选型时主要看任务边界：如果边界清晰、领域固定，专用 Agent 通常更轻便高效；如果边界会变化、需要长期处理多种类型的任务，才值得上通用操作系统。两者底层都依赖某种 Harness，差别只在于优化目标——一个是单领域精耕，一个是多任务托管。

吴恩达的 Agentic Workflows，跑在底座上的协作模式

吴恩达更看重 AI Agentic Workflows（代理式工作流），认为它比空谈 AI Agent 更有落地意义。他归纳四种代理式工作流模式，Reflection（反思与自我修正）、Tool Use（工具调用）、Planning（规划与分解）、Multi-agent Collaboration（多智能体协作）。

四种模式讲 Agent 怎么协作与推理；Agent Harness 讲这些模式跑在什么运行环境上。Workflow 模式是编排语言，Harness 是执行底座。后面讲协作模式与五维框架时，这四条会反复出现。

概念对照，什么时候要关心它

概念清楚了，我们接下来讨论“要不要 Agent”的过滤器，从而帮助识别什么情况才需要Agent？

先过滤：真的需要 Agent 吗？

在进入场景分类之前，第一步要做的是判断：这个任务到底需不需要 Agent。

Anthropic 在《Building Effective Agents》中讲得很直白：先找最简单的可行方案，只在确实需要时才增加复杂度。他们把系统分为两类：

• • 工作流（Workflow）：LLM 和工具按照预先写死的路径编排执行。
• • 智能体（Agent）：系统动态决定自己的操作流程和工具调用方式。

两者的界限只有一条——任务路径是固定的，还是需要模型在运行时自己判断下一步。

OpenAI 在《A Practical Guide to Building Agents》中也给出了三个“值得上 Agent”的条件：涉及复杂决策、规则难以硬编码维护、重度依赖非结构化数据。如果三点都不满足，原文的判断是：确定性方案往往就够用了。

这个判断标准可以概括为一句话：路径确定，工作流就够；路径不确定，才需要 Agent。

只有过了这道筛选门槛，才值得继续往下谈场景分类和架构设计。完整的决策链路是三步：要不要 Agent → 属于哪类场景 → 采用什么架构。

四象限，用复杂度和交互模式切场景

场景矩阵只用两个维度。

复杂度。 低复杂度是一步能完成的事；高复杂度需要多步骤、多工具协作。

交互模式。 单向是用户发指令、系统返回结果即结束；多轮需要来回对话、记忆上下文、持续跟进。

两维交叉出四个象限，每个象限对应一类架构。

象限①最轻。一个 Agent、一次工具调用、一个结果。多数团队的起点都在这里。

象限②仍是单向，但一个工具搞不定。典型指令长这样。并行收集比亚迪公司最近 3 份券商（华泰证券、广发证券、招商证券）研报，提取目标价、评级、核心观点，生成一份 500 字的对比分析摘要。这件事至少拆成多步，打开浏览器访问多个数据源、抓取网页、提取关键信息、对比分析、生成摘要、保存文件。任一步都可能失败。因此关键词落在多工具编排、任务拆解、失败回退。

象限③单步并不难，但依赖记忆。用户说“改到明天”，系统必须知道改的是哪一件事。架构上靠两件事，Memory 记住上下文，Skill 复用固定流程。

象限④同时要求多工具协作与持续状态。常见形态是分工，A 采集、B 清洗、C 出报告、D 发邮件，每个 Agent 只盯一件事。

落到真实业务，对号入座往往比记表格更要紧。摘要／总结／翻译多落在象限①；数据分析多落在②；客服／助理多落在③；研报／端到端流水线多落在④。决策链是，要不要 → 哪类场景 → 什么架构。 别一上来就选工具。

企业视角，专精 × 高复杂度才是转型核心

再抬一层看企业需要什么样的 Agentic 系统。横轴仍是复杂度（低 → 高），纵轴换成能力（通用 → 垂直 → 专精）。

通用 × 低复杂度，个体任务，市面通用工具就够。通用 × 高复杂度能跑，但质量和稳定性没保障。专精 × 低复杂度是企业级单专家任务。专精 × 高复杂度，才是企业业务转型的核心。 落地价值落在跨系统的核心流程上，单次问答撑不起转型。

这条赛道已经拥挤，但迄今还没有人打通从“自主规划”到“决策”再到“执行”的完整闭环。高复杂度下的专业化能力加上自主决策，尚未被充分验证。空白里藏着机会，要靠流程编排与数据驱动的决策。所以象限④必须认真对待多智能体协作。

编排词汇，Anthropic 的五种工作流模式

讲多工具编排时，Anthropic《Building Effective Agents》总结的五种模式正好覆盖不同复杂度。

• • 链式提示（Prompt Chaining）。大任务拆成固定子任务，前一步输出喂后一步。落在象限①到②的过渡带。
• • 路由（Routing）。按输入类型分流。对应象限①里的分类场景。
• • 并行化（Parallelization）。任务分片，多个 LLM 同时处理再汇总。对应象限②的多数据源并行采集。
• • 编排-执行者（Orchestrator-Workers）。主 Agent 动态拆解任务，分给多个子 Agent。与并行化的关键差别是子任务事先不可预知。对应象限②到④。
• • 评估-优化器（Evaluator-Optimizer）。一个 LLM 生成，另一个按明确标准评估，不达标就退回重做。

五种模式可以组合，并不互斥。

单智能体与多智能体，三个天花板，再谈硬数字

落在象限④只是起点。真实问题是，多个 Agent 之间如何协作？多智能体按交互模式动态协作，构成端到端系统。多个单智能体简单拼在一起，撑不起这件事。判断依据是单智能体的三个天花板。

天花板一（Context 窗口）。 复杂任务一开跑，研报、历史对话、中间推理、工具结果可能同时堆进来，很容易顶满窗口。Anthropic 在《Effective Context Engineering for AI Agents》里称这种现象为 context rot（上下文腐化），上下文变长后，模型注意力按 n² 级稀释。对策有三类，压缩（compaction）、结构化笔记（agentic memory）、子代理架构。

天花板二（能力边界）。 一个 Agent 很难同时当好金融专家、代码专家和设计专家。工具越多，注意力越散，出错率越高。

天花板三（并发能力）。 单 Agent 串行。要同时采 5 个数据源时，只能排队，耗时近似线性增长。

收益与代价的硬数字

Anthropic 复盘自家多智能体研究系统时报告，主 Agent（Opus 4）加子 Agent 的架构在内部评测上比单 Agent Opus 4 高 90.2%。代价出在 token。单 Agent 用量大约是普通聊天的 4 倍，多 Agent 大约是 15 倍。原话是，Multi-agent systems work mainly because they help spend enough tokens to solve the problem.

另一组数字来自吴恩达 Agentic Design Patterns 系列信。GPT-3.5 零样本在 HumanEval 上 48.1%，GPT-4 零样本 67.0%；把 GPT-3.5 包进迭代式智能体工作流，可以到 95.1%。口径需要写清，95.1% 是 AI Fund 汇总多种已发表智能体算法的 up to 最优值，HumanEval 已被业界视为饱和或污染，属 Ng 2024 年分析，只宜看趋势。这组数字仍说明一件事，架构选择往往比换一代模型更划算。

选用条件与伸缩经验

单智能体三个条件（同时满足就优先用单），任务一步能完成；上下文可控、不会溢出；不需要并行。

多智能体三个信号（出现任一就考虑多），任务超出单一角色能力；需要并行加速（同时采 5 份研报时，单 Agent 串行约 5 分钟，5 个 Agent 并行约 1 分钟）；需要专业分工。

多 Agent 堆太多也没用。Anthropic 的工作量伸缩经验是，简单任务 1 个 Agent、3 到 10 次工具调用即可；对比类任务 2 到 4 个子 Agent，每个 10 到 15 次调用；复杂研究才上超过 10 个子 Agent。并行调用最多可省约 90% 的研究时间；超过 10 个子 Agent 后，编排复杂度急剧上升，收益递减。

四种交互模式

多智能体怎么协作？四种交互模式，非互斥，可分阶段组合。Orchestrator-Worker 解决“谁来做”，Creator-Verifier 解决“做对了吗”。

① Pipeline（流水线）。 任务拆成固定步骤，后一步处理前一步输出。适合能干净拆成固定子任务的流程；目的是让每次调用更简单，用延迟换准确性。

② Parallelization（并行化）。 并行处理多个子任务，输出再程序化整合。两种常见形态，分割（独立子任务并行）与投票（同一任务多次执行再汇总）。适合子任务可并行，或需要多视角提高可靠性。

③ Orchestrator-Worker（编排-执行者）。 协调者规划汇总，执行者干活。与 Parallelization 的关键差别在于，子任务由协调者根据输入现场决定，事先并不固定。关键问题是任务边界是否清晰、每个子任务是否有明确输入／输出。

④ Creator-Verifier（生成-验证）。 生成与评估分离，防止幻觉累积。验证标准必须可检查、可量化。标准要写成“包含 3 个数据源、500 字摘要、正确署名”，笼统说“写得好”过不了关。适合有明确评估标准、迭代能产生可测价值的任务。

用“2026年全球人工智能芯片产业深度研报”走一遍组合，资料采集用 Parallelization；任务分配用 Orchestrator-Worker；撰写用 Pipeline（提纲 → 初稿 → 成稿）；质量把关用 Creator-Verifier。一个真实行研项目，四种模式在不同阶段接力，这才是端到端系统的含义。

共同约束只有一条。每个 Agent 只专注一件事。

用 Google L0 到 L3 做自我定位

Google《Introduction to Agents》白皮书把智能体分级。L0 核心推理是裸模型；L1 连接型接上了工具；L2 战略型有了上下文工程和多步规划；L3 协作型是多智能体协同，agents treat other agents as tools。白皮书还有 L4 自进化，宜当作远期愿景。

上文的场景矩阵、四种交互模式与五维框架，主要覆盖 L2 到 L3。团队若仍在 L1，先把工具接稳；已到 L2，再考虑如何拆成多 Agent 协作。

五维构建框架，把“靠谱”拆成可检查项

落地时常见五个困境，业务不敢用（缺界限）、过程不可控（缺执行与回退）、结果难评估（缺验收标准）、资产难沉淀（缺复用）、责任界定难（缺治理）。对应收成五维构建框架，自下而上搭。边界层是地基，治理层是天花板。五个维度都考虑到，方案才站得住。

下面用一套真实落地的 Hermes 多智能体配置作主例子。五个专家 profile 组成同一个 Agent 组，编排走 Hermes 的 kanban（看板任务、运行记录与事件流）。后文的券商研报 Demo 就是这条链路的端到端验收。

五个专家，边界先写进角色

边界层最基础，也最容易被跳过。更优先的规定是不能做什么。在这套 Hermes 配置里，边界首先写成五个专家的职责画像，事后补一句“小心一点”不够。

• • planner，接收用户任务、判断类型、分配给对应专家；自己不直接把活干完。
• • researcher，提取目标公司财务数据、行业数据与公开披露信息。
• • analyst，深度财务分析、行业逻辑推理，并建立估值模型。
• • writer，把分析逻辑与估值结论写成标准化券商深度研究报告。
• • reviewer，对初稿做事实核查、逻辑穿透测试与表达审查。

五个角色同属一个 Agent 组。谁能碰公开源、谁只能写研报正文、谁负责挑错，在 profile 里先钉死；系统级的脱敏、工具白名单与沙箱再叠一层。研报场景里，行情、财报、行业新闻与券商观点可读；交易系统、下单入口全程不在白名单内。

执行层，kanban 上的 Orchestrator-Worker

执行层的重心在拆解与失败回退。单个数据源挂掉不应拖垮整单。

落地时，planner 充当编排者（Orchestrator-Worker），把“写一份深度研报”拆成可派发的工作项，写上看板。researcher、analyst、writer、reviewer 按角色认领对应卡片；每次执行写入运行记录，关键节点留下事件流，便于事后排查是哪一步、哪位专家出了问题。采集阶段仍可并行抓取多个公开源（Parallelization）；某一源失败则跳过、标记、继续。看板把“谁在做、做到哪、失败几次”变成可观察状态，黑盒里的一次长对话做不到这一点。

验证层与治理层

验证层先落到可检查交付物，再落到独立角色。writer 生成初稿，reviewer 按 Creator-Verifier 模式另开验证回合，事实能否对上源材料、财务勾稽是否一致、风险提示是否齐全。少一条，DoD 就不通过；需要返工时，精准退回 writer，不必整单推倒重来。

离线评估仍可沿用行业做法。Anthropic 的起步评估法建议先从真实业务攒 20 条真实 query，再用 LLM-judge 按五个维度打分（准确性、引用质量、完整性、来源质量、工具效率），每维 0.0 到 1.0。LangChain 的故障二分法要求出错时先分清是模型本身错了，还是上下文给错了。

治理层不止“人点一下确认”。在这套路里，分析逻辑与初步评级过关、初稿签发、对外发布等动作，都作为看板关卡留给持牌分析师；Agent 只做分析，不做最终决策。OpenAI《A Practical Guide to Building Agents》把护栏分成 7 层，相关性分类器、安全分类器、PII 过滤器、内容审核、工具护栏、规则式保护、输出校验。工具护栏可落成风险表，读数据低风险可自动放行并记日志；写文件中风险，沙箱内执行、超范围需确认；交易系统禁止 Agent 直接调用，必须人工审批。人工介入只有两类触发，失败次数超阈值，或高风险／不可逆动作。12-Factor Agents 的 Factor 7 把这一点工程化，用工具调用联系人类，人工审批嵌在系统之内。

资产层回答“下次能否一键复用”。五个专家 profile 与同一 Agent 组是可迁移的协作骨架；跑通后的流程再存成 Skill（与 Anthropic Agent Skills 开放标准同构），卖方格式、DCF 模型与词库才能跨公司复用。

三个案例，五维逐层落地

财务／采购“发票与报销审批 Agent”。 边界，只读 OA 与发票 OCR，严禁向银行或支付系统发起资金划转。执行，识别发票 → 匹配报销标准与预算 → 不合规则回退并通知补交。验证，抬头与公司全称 100% 匹配，金额无误，税号真实有效。资产，沉淀发票 OCR Skill 与预算比对脚本。治理，合规审查可自动；打款或超过 5,000 元报销必须财务主管人工审批。

运维／IT“自动化故障排查 Agent”。 边界，可读日志与监控，严禁对生产库或主服务器执行破坏性写操作。执行，告警 → 收集近 15 分钟指标与日志 → 重试节点；连续 3 次失败则降级挂起。验证，健康检查返回 200，API 延迟恢复至 100ms 以内。资产，日志检索 Tool 与重启 SOP 模板。治理，诊断可自动；重启核心库必须值班人员确认。

HR“候选人筛选与面试安排 Agent”。 边界，仅可访问面试日历与指定 Resume 邮箱，严禁读薪酬档案。执行，解析简历 → 匹配 JD → 发邀约 → 协调日历；拒绝则二次匹配。验证，年限／学历过硬性阈值，日历无冲突。资产，简历结构化 Skill 与多方日历匹配 Tool。治理，AI 初筛并生成推荐摘要，是否发面试邀请由 HR 勾选确认。

共同点是，每一层都有具体、可检查的设计，一句“让 Agent 去做”不够。

案例，券商研报撰写（具身智能龙头）

再用高复杂度场景做闭环，验收上文那套 Hermes 五专家 + kanban 配置。实战任务是，为某具身智能龙头公司撰写券商研报初稿，采集公开数据源（行情、财报、行业新闻、券商观点），提取关键数据与核心观点，生成包含投资要点、财务分析、估值与风险提示的研报初稿，保存为 research-report.md。

这是典型的单向高复杂度（象限②），需要多工具编排与子 Agent 协作；加上撰写与核查，已经摸到象限④的边。

执行沿看板展开。planner 接单后拆解并派发（执行层，也是 Orchestrator-Worker），researcher 采集行情与财务、行业新闻与政策、券商观点与可比公司；analyst 做逻辑推理与估值建模；writer 写成标准化研报初稿；reviewer 做验证层终审。采集阶段可并行抓取多个公开源（Parallelization）；边界层同时生效，可读公开源，不能碰交易系统、不能下单。某一源失败则跳过、标记并继续。writer 与 reviewer 构成 Creator-Verifier，初稿不过关就精准退回修改，不必整单重跑。

验证层硬性条件是，数据有来源、财务勾稽一致、必须包含风险提示，少一条都不算完成。

随后把流程存为 research-analyst Skill。换公司名即可复用，这是资产层的价值。Skill 保存机制与 Anthropic 的 Agent Skills 开放标准（github.com/anthropics/skills）同构，用 SKILL.md 定义技能，含 YAML frontmatter 与正文指令。五个专家 profile 与 Agent 组本身也是可复用资产，换标的、不换协作骨架。

五维验收可以逐项对照。边界，角色职责写进 profile，公开源可读，交易系统不可碰，planner 不直接执行。执行，kanban 拆解派发，专家认领，失败可回退。验证，reviewer 事实匹配 100%、勾稽 0 误差、必须含风险提示。资产，沉淀 Skill、Prompt、词库与专家组。治理，合规投资评级人确认，发布前首席分析师签发。Agent 只做分析，不做决策；发布这个动作，必须人来点。

五维收束，边界避免违法违规（泄密／越权交易）；执行保证自动化且出错可精准回退；验证提供量化 DoD，避免“假幻觉”报告；资产统一卖方格式与计算模型（如 DCF Skill）；治理把评级与发布权留在人类持牌专家手中。

带走的四段路径

1. 1. 场景分类（四象限）。 复杂度 × 交互模式，拿到业务需求先对号入座，场景决定架构。
2. 2. 协作模式（四种交互）。 Pipeline、Parallelization、Orchestrator-Worker、Creator-Verifier，非互斥，可分阶段组合。
3. 3. 五维构建（边界 → 治理）。 边界层是地基，治理层是天花板，五维都考虑到方案才靠谱。小项目可先做边界、执行、验证，再补资产与治理。
4. 4. 实战验证（清单打钩）。 做完以后还要对照五维清单逐维验证，形成闭环；跑通后存为 Skill，在团队内复用。

原则是先跑通，再优化。

延伸阅读

第一阶段（1 到 2 周）用 Hermes 跑通一个象限①小场景；

第二阶段（2 到 4 周）用四种交互模式搭多 Agent 端到端场景，并用五维框架补齐设计；

第三阶段（持续）把流程沉淀为 Skill，建立团队资产库。

打基础（约 1 到 2 周）。 Datawhale《Hello-Agents，从零开始构建智能体》（github.com/datawhalechina/hello-agents）；Hugging Face Agents Course 中文版（huggingface.co/learn/agents-course/zh-CN）；Anthropic《Building Effective Agents》社区中译。

动手练（约 2 到 4 周）。 Kaggle 5-Day AI Agents Intensive；OpenAI Agents SDK 的 research_bot 示例；LangGraph Supervisor 教程。

体系化（持续）。 微软《AI Agents for Beginners》18 课；DeepLearning.AI 短课系列；12-Factor Agents 中译。《Agentic 智能体设计模式》（Antonio Gullí，清华大学出版社 2026-05）是 21 章模式专著。

术语可统一如下。agent 译“智能体”（不用“代理”）；orchestrator-workers 称“主从”或按课内交互模式名保留英文；guardrail 称“护栏”；human-in-the-loop 称“人在回路”；skill 保留英文；context rot 首次给英文，其后可用“上下文腐化”。

引用来源

• • Anthropic,《Building Effective Agents》，anthropic.com/engineering/building-effective-agents
• • Anthropic,《How We Built Our Multi-Agent Research System》，anthropic.com/engineering/built-multi-agent-research-system
• • Anthropic,《Effective Context Engineering for AI Agents》，anthropic.com/engineering/effective-context-engineering-for-ai-agents
• • OpenAI,《A Practical Guide to Building Agents》，cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
• • Google,《Introduction to Agents》，kaggle.com/whitepaper-introduction-to-agents
• • 吴恩达, Agentic Design Patterns Part 1，deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/
• • 12-Factor Agents，github.com/humanlayer/12-factor-agents (CC BY-SA 4.0)
• • anthropics/skills，github.com/anthropics/skills
• • Model Context Protocol，modelcontextprotocol.io