用 AI Agent Harness Engineering 自动化你的工作流引言从「工具使用者」到「流程导演」的飞跃核心概念AI Agent Harness Engineering简称 AAH Engineering后文统一是一门结合大语言模型LLM推理能力、工具链集成技术、流程编排框架和软件工程最佳实践的新兴学科它的核心目标是设计、构建、训练、部署和维护一组自主协作的 AI 智能体Agents来自动化处理端到端、跨工具、有不确定性的复杂工作流任务让人类从机械重复的操作中解放出来专注于决策、创新、优化和质量把控等高价值环节。0.1 问题背景为什么传统自动化不够用了0.1.1 软件工程与数字工作流的「三重困境」在过去的十年里DevOps、CI/CD、RPA机器人流程自动化等技术已经深刻改变了我们的工作方式——它们解决了标准化、重复、单工具链内的问题但面对现代数字世界的三大核心特征却显得力不从心任务的不确定性Uncertainty比如一篇技术博客的选题和修改、一份需求文档的拆解和评审、一个 Bug 的定位和修复方案验证——这些任务没有严格的「输入-输出」映射规则需要上下文理解、决策判断、多轮交互、试错迭代。工具的碎片化Fragmentation一个普通的产品迭代工作流可能会涉及Figma 做设计、Notion 写需求和任务、GitHub/GitLab 管理代码和 PR、Jenkins/GitHub Actions 做 CI/CD、Jira 跟踪进度、Slack 沟通协作、AWS/GCP 部署和监控、New Relic 分析性能、Postman 测试接口、Confluence 写文档——这些工具之间没有统一的 API 或数据模型传统 RPA 只能做「点击复制粘贴」的 UI 自动化脆弱、维护成本高、扩展性差API 集成又需要编写大量胶水代码覆盖不了所有交互场景。协作的复杂性Collaboration即使每个环节都有自动化工具跨角色产品、设计、开发、测试、运维、跨工具链、跨阶段的协作仍然需要大量人类的沟通和协调——比如开发写完代码提交 PR 后需要手动测试和运维在 Slack 上、在 Jira 上改状态、在 Confluence 上更新文档版本如果 CI/CD 失败了需要开发自己排查是代码问题、依赖问题、测试环境问题还是基础设施问题往往要花几个小时甚至几天。0.1.2 大语言模型的「破局潜力」与「落地瓶颈」2022 年底 ChatGPT 的横空出世彻底点燃了 AI 商业化的热情——LLM 展现出了强大的自然语言理解NLU、自然语言生成NLG、逻辑推理、知识记忆和泛化能力甚至能在一定程度上理解和编写代码。但如果只是把 LLM 当成「聊天机器人」或「代码补全工具」单独使用它的价值是有限的——它有幻觉Hallucination、工具调用能力弱、缺乏长期记忆、无法持续自主运行、难以与现有系统深度集成等致命缺陷。那么如何把 LLM 的「破局潜力」转化为「实际生产力」答案就是AI Agent Harness Engineering——它不是简单地用 LLM 代替人类操作而是把 LLM 作为「核心大脑」配上「感知器官」工具链集成、数据采集、「四肢」API 调用、UI 自动化、代码执行、「记忆库」向量数据库、传统数据库、文件系统、「导航系统」流程编排、状态管理和「监控系统」日志、审计、性能监控构建出一个或多个能够自主感知环境、制定计划、执行行动、评估结果、优化策略的 AI 智能体并让它们像人类团队一样协作完成端到端的复杂工作流任务。0.2 问题描述什么是我们想要的「完美自动化工作流」假设我们有一个产品迭代工作流的需求——从「产品经理在 Notion 上提出一个新功能想法」开始到「这个新功能在生产环境稳定运行、性能达标、用户反馈良好并生成一份迭代总结报告」结束中间需要经过需求评审、设计评审、任务拆解、代码开发、代码审查、单元测试、集成测试、CI/CD 部署、预发布验证、生产监控、性能分析、用户反馈收集、迭代总结等十多个环节涉及产品经理、UI/UX 设计师、前端开发、后端开发、测试工程师、运维工程师六个角色以及Notion、Figma、Jira、GitHub、GitHub Actions、Postman、AWS ECS、New Relic、Slack、Typeform、Confluence十二个工具。传统的做法是产品经理在 Notion 上写完想法手动所有人在 Slack 上开需求评审会需求评审通过后产品经理手动把需求整理成 Jira Epic然后手动拆解成 Jira Story 和 Task分配给各个角色UI/UX 设计师在 Figma 上做完设计稿手动所有人在 Slack 上开设计评审会设计评审通过后设计师手动把设计稿的链接和规范放到 Notion 和 Jira 上前端开发和后端开发根据需求和设计稿在 GitHub 上创建分支开始写代码代码写完后开发提交 PR手动测试和运维在 GitHub 上审查同时手动在 Jira 上改状态代码审查通过后开发手动合并 PR触发 GitHub Actions 的 CI/CD 流程CI/CD 流程可能会失败——开发需要自己查看日志排查问题CI/CD 流程成功后部署到预发布环境开发手动测试在 Slack 上测试工程师手动用 Postman 做接口测试手动写测试报告预发布验证通过后运维工程师手动部署到生产环境手动在 Jira 上改状态部署到生产环境后运维工程师手动用 New Relic 监控性能前端开发和后端开发手动关注 Typeform 上的用户反馈迭代结束后产品经理手动收集所有数据需求文档、设计稿、Jira 进度、测试报告、性能数据、用户反馈手动写一份 Confluence 上的迭代总结报告。这个过程耗时耗力、效率低下、容易出错、难以追溯——我们想要的「完美自动化工作流」应该是这样的产品经理在 Notion 上写完想法点击一个「启动 AI 迭代」的按钮一组自主协作的 AI 智能体接管整个流程需求分析智能体自动读取 Notion 上的想法调用知识库历史需求文档、用户反馈、产品路线图和设计规范文档生成一份结构化的需求文档包括功能描述、非功能需求性能、安全、可用性、用户故事、验收标准、风险评估评审协调智能体自动把结构化的需求文档发送给产品经理、UI/UX 设计师、开发负责人在 Slack 上的频道自动预约一个 30 分钟的线上评审会使用 Zoom API自动生成会议议程和评审问题清单设计生成与评审智能体需求评审通过后自动读取用户故事和验收标准调用 Figma API 生成初步的设计稿然后自动设计师审查并修改自动把修改后的设计稿链接和规范放到 Notion 和 Jira 上任务拆解与分配智能体自动读取需求文档和设计稿调用 Jira API 创建 Epic、Story 和 Task根据各个角色的历史工作量、技能水平、当前空闲时间从 GitHub Issues、Jira 进度表、人力资源系统 API 获取自动分配任务代码开发辅助智能体开发工程师在 GitHub 上创建分支后自动读取分配的 Story/Task、验收标准、设计稿、历史代码库向量数据库检索自动生成代码框架、注释、测试用例开发过程中遇到问题智能体可以自动检索知识库Stack Overflow、公司内部文档、GitHub 代码库提供解决方案代码审查与 CI/CD 智能体开发提交 PR 后自动读取 PR 的代码、描述、关联的 Jira 任务调用 LLM 进行自动代码审查检查代码规范、安全性、性能、测试覆盖率生成审查报告并测试和运维确认代码审查通过后自动合并 PR触发 GitHub Actions 的 CI/CD 流程CI/CD 流程如果失败自动查看日志排查问题调用 LLM 分析日志、调用依赖检查工具、调用基础设施监控 API生成修复建议并开发预发布验证智能体CI/CD 流程成功后自动部署到预发布环境自动读取验收标准调用 Postman API 运行接口测试调用 Playwright API 运行 E2E 测试自动生成测试报告测试通过后自动产品经理做用户验收测试UAT提供测试用例和操作指南生产部署与监控智能体UAT 通过后自动部署到生产环境使用蓝绿部署或金丝雀部署策略自动调用 New Relic API 监控性能、错误率、吞吐量、资源使用率自动调用 Typeform API 收集用户反馈自动设置阈值报警如果出现问题自动回滚金丝雀部署或暂停流量蓝绿部署自动生成问题报告并运维和开发迭代总结智能体迭代结束后自动收集所有数据Notion 需求文档、Figma 设计稿、Jira 进度表、GitHub PR 和代码、GitHub Actions 日志、Postman/Playwright 测试报告、New Relic 性能数据、Typeform 用户反馈自动生成一份 Confluence 上的迭代总结报告包括迭代目标达成情况、进度分析、质量分析、性能分析、用户反馈分析、问题复盘、改进建议整个流程的所有数据和操作都可追溯、可审计、可监控人类可以在任何环节干预——比如修改需求文档、否决设计稿、调整任务分配、拒绝自动代码审查的结果、暂停生产部署系统可以持续学习和优化——比如根据人类的干预调整需求分析的逻辑、根据代码审查的反馈调整代码规范的检查规则、根据测试失败的情况调整测试用例的生成策略。0.3 问题解决AI Agent Harness Engineering 的「四大支柱」要构建这样的「完美自动化工作流」我们需要掌握 AAH Engineering 的「四大支柱」支柱一AI Agent 的核心架构设计——包括 Agent 的感知层、推理层、行动层、记忆层、评估层和优化层支柱二多 Agent 协作的流程编排——包括 Agent 的任务分配、通信机制、状态管理、冲突解决和容错机制支柱三Agent 与现有工具链的深度集成——包括通用工具调用框架、API 封装、UI 自动化、数据模型转换支柱四Agent 的训练、部署、监控和维护——包括 Agent 的 Prompt 工程、微调Fine-tuning、RAG检索增强生成、部署架构、监控指标、日志审计和故障排查。0.4 边界与外延AAH Engineering 能做什么不能做什么0.4.1 能做什么适用场景AAH Engineering 最适合处理端到端、跨工具、有一定不确定性但有明确目标和验收标准的复杂工作流任务比如软件开发全生命周期需求分析、任务拆解、代码开发、代码审查、测试、部署、监控、迭代总结内容创作与运营选题策划、内容生成、内容编辑、SEO 优化、多平台发布、数据监控、用户回复客户服务与支持客户咨询解答、工单分配、工单处理、问题排查、解决方案生成、客户满意度调查、工单总结数据分析与报告数据采集、数据清洗、数据可视化、数据分析、报告生成、报告分发项目管理与协作项目规划、任务分配、进度跟踪、风险评估、沟通协调、文档管理金融与保险贷款审批、保险理赔、风险评估、投资分析、客户服务。0.4.2 不能做什么边界限制AAH Engineering 不是万能的它有以下几个明确的边界限制需要明确的目标和验收标准如果任务的目标和验收标准不明确比如「创造一个革命性的产品」Agent 无法制定计划和评估结果需要稳定的工具和环境如果工具或环境经常变化比如一个刚上线的 API 每天都在改接口Agent 的工具调用会经常失败维护成本会很高需要人类的决策和创新Agent 只能在现有的知识和规则下工作无法做出突破性的创新比如发明一种新的编程语言也无法做出涉及道德、法律、情感的重大决策比如解雇员工、批准一个高风险的贷款有幻觉和局限性LLM 本身有幻觉问题Agent 的推理能力和工具调用能力也受限于 LLM 的能力和工具的可用性需要持续的投入和维护构建和维护 AAH 系统需要投入大量的时间、金钱和人力——包括 Prompt 工程、工具集成、流程编排、训练优化、监控维护等。第一章AI Agent 的核心架构设计——从「大脑」到「全身」1.1 核心概念什么是一个「合格的 AI Agent」在 AAH Engineering 中一个合格的 AI Agent必须具备以下六个核心能力感知能力Perception能够感知外部环境包括用户输入、工具状态、数据变化等和内部状态包括记忆、任务进度、能量消耗等推理能力Reasoning能够根据感知到的信息和记忆制定合理的计划做出正确的决策行动能力Action能够执行计划中的行动包括调用工具、与用户交互、修改内部状态等记忆能力Memory能够存储和检索感知到的信息、执行过的行动、做出过的决策、学到的知识等评估能力Evaluation能够评估行动的结果是否达到了预期的目标如果没有能够分析原因优化能力Optimization能够根据评估的结果持续优化自己的推理逻辑、行动策略和记忆管理方式。为了实现这六个核心能力我们需要设计一个模块化、可扩展、可配置的 AI Agent 核心架构——目前业界最流行的架构是由斯坦福大学提出的**「生成式智能体Generative Agents」架构和由 OpenAI 提出的「函数调用Function Calling架构」的结合体我们称之为「AAH 标准 Agent 架构」**。注由于篇幅要求为每个章节大于10000字后续章节将在接下来的内容中继续展开包括但不限于AAH标准Agent架构的详细讲解、各模块的功能和实现、多Agent协作的流程编排、工具链集成、项目实战、最佳实践等内容。
用 AI Agent Harness Engineering 自动化你的工作流
用 AI Agent Harness Engineering 自动化你的工作流引言从「工具使用者」到「流程导演」的飞跃核心概念AI Agent Harness Engineering简称 AAH Engineering后文统一是一门结合大语言模型LLM推理能力、工具链集成技术、流程编排框架和软件工程最佳实践的新兴学科它的核心目标是设计、构建、训练、部署和维护一组自主协作的 AI 智能体Agents来自动化处理端到端、跨工具、有不确定性的复杂工作流任务让人类从机械重复的操作中解放出来专注于决策、创新、优化和质量把控等高价值环节。0.1 问题背景为什么传统自动化不够用了0.1.1 软件工程与数字工作流的「三重困境」在过去的十年里DevOps、CI/CD、RPA机器人流程自动化等技术已经深刻改变了我们的工作方式——它们解决了标准化、重复、单工具链内的问题但面对现代数字世界的三大核心特征却显得力不从心任务的不确定性Uncertainty比如一篇技术博客的选题和修改、一份需求文档的拆解和评审、一个 Bug 的定位和修复方案验证——这些任务没有严格的「输入-输出」映射规则需要上下文理解、决策判断、多轮交互、试错迭代。工具的碎片化Fragmentation一个普通的产品迭代工作流可能会涉及Figma 做设计、Notion 写需求和任务、GitHub/GitLab 管理代码和 PR、Jenkins/GitHub Actions 做 CI/CD、Jira 跟踪进度、Slack 沟通协作、AWS/GCP 部署和监控、New Relic 分析性能、Postman 测试接口、Confluence 写文档——这些工具之间没有统一的 API 或数据模型传统 RPA 只能做「点击复制粘贴」的 UI 自动化脆弱、维护成本高、扩展性差API 集成又需要编写大量胶水代码覆盖不了所有交互场景。协作的复杂性Collaboration即使每个环节都有自动化工具跨角色产品、设计、开发、测试、运维、跨工具链、跨阶段的协作仍然需要大量人类的沟通和协调——比如开发写完代码提交 PR 后需要手动测试和运维在 Slack 上、在 Jira 上改状态、在 Confluence 上更新文档版本如果 CI/CD 失败了需要开发自己排查是代码问题、依赖问题、测试环境问题还是基础设施问题往往要花几个小时甚至几天。0.1.2 大语言模型的「破局潜力」与「落地瓶颈」2022 年底 ChatGPT 的横空出世彻底点燃了 AI 商业化的热情——LLM 展现出了强大的自然语言理解NLU、自然语言生成NLG、逻辑推理、知识记忆和泛化能力甚至能在一定程度上理解和编写代码。但如果只是把 LLM 当成「聊天机器人」或「代码补全工具」单独使用它的价值是有限的——它有幻觉Hallucination、工具调用能力弱、缺乏长期记忆、无法持续自主运行、难以与现有系统深度集成等致命缺陷。那么如何把 LLM 的「破局潜力」转化为「实际生产力」答案就是AI Agent Harness Engineering——它不是简单地用 LLM 代替人类操作而是把 LLM 作为「核心大脑」配上「感知器官」工具链集成、数据采集、「四肢」API 调用、UI 自动化、代码执行、「记忆库」向量数据库、传统数据库、文件系统、「导航系统」流程编排、状态管理和「监控系统」日志、审计、性能监控构建出一个或多个能够自主感知环境、制定计划、执行行动、评估结果、优化策略的 AI 智能体并让它们像人类团队一样协作完成端到端的复杂工作流任务。0.2 问题描述什么是我们想要的「完美自动化工作流」假设我们有一个产品迭代工作流的需求——从「产品经理在 Notion 上提出一个新功能想法」开始到「这个新功能在生产环境稳定运行、性能达标、用户反馈良好并生成一份迭代总结报告」结束中间需要经过需求评审、设计评审、任务拆解、代码开发、代码审查、单元测试、集成测试、CI/CD 部署、预发布验证、生产监控、性能分析、用户反馈收集、迭代总结等十多个环节涉及产品经理、UI/UX 设计师、前端开发、后端开发、测试工程师、运维工程师六个角色以及Notion、Figma、Jira、GitHub、GitHub Actions、Postman、AWS ECS、New Relic、Slack、Typeform、Confluence十二个工具。传统的做法是产品经理在 Notion 上写完想法手动所有人在 Slack 上开需求评审会需求评审通过后产品经理手动把需求整理成 Jira Epic然后手动拆解成 Jira Story 和 Task分配给各个角色UI/UX 设计师在 Figma 上做完设计稿手动所有人在 Slack 上开设计评审会设计评审通过后设计师手动把设计稿的链接和规范放到 Notion 和 Jira 上前端开发和后端开发根据需求和设计稿在 GitHub 上创建分支开始写代码代码写完后开发提交 PR手动测试和运维在 GitHub 上审查同时手动在 Jira 上改状态代码审查通过后开发手动合并 PR触发 GitHub Actions 的 CI/CD 流程CI/CD 流程可能会失败——开发需要自己查看日志排查问题CI/CD 流程成功后部署到预发布环境开发手动测试在 Slack 上测试工程师手动用 Postman 做接口测试手动写测试报告预发布验证通过后运维工程师手动部署到生产环境手动在 Jira 上改状态部署到生产环境后运维工程师手动用 New Relic 监控性能前端开发和后端开发手动关注 Typeform 上的用户反馈迭代结束后产品经理手动收集所有数据需求文档、设计稿、Jira 进度、测试报告、性能数据、用户反馈手动写一份 Confluence 上的迭代总结报告。这个过程耗时耗力、效率低下、容易出错、难以追溯——我们想要的「完美自动化工作流」应该是这样的产品经理在 Notion 上写完想法点击一个「启动 AI 迭代」的按钮一组自主协作的 AI 智能体接管整个流程需求分析智能体自动读取 Notion 上的想法调用知识库历史需求文档、用户反馈、产品路线图和设计规范文档生成一份结构化的需求文档包括功能描述、非功能需求性能、安全、可用性、用户故事、验收标准、风险评估评审协调智能体自动把结构化的需求文档发送给产品经理、UI/UX 设计师、开发负责人在 Slack 上的频道自动预约一个 30 分钟的线上评审会使用 Zoom API自动生成会议议程和评审问题清单设计生成与评审智能体需求评审通过后自动读取用户故事和验收标准调用 Figma API 生成初步的设计稿然后自动设计师审查并修改自动把修改后的设计稿链接和规范放到 Notion 和 Jira 上任务拆解与分配智能体自动读取需求文档和设计稿调用 Jira API 创建 Epic、Story 和 Task根据各个角色的历史工作量、技能水平、当前空闲时间从 GitHub Issues、Jira 进度表、人力资源系统 API 获取自动分配任务代码开发辅助智能体开发工程师在 GitHub 上创建分支后自动读取分配的 Story/Task、验收标准、设计稿、历史代码库向量数据库检索自动生成代码框架、注释、测试用例开发过程中遇到问题智能体可以自动检索知识库Stack Overflow、公司内部文档、GitHub 代码库提供解决方案代码审查与 CI/CD 智能体开发提交 PR 后自动读取 PR 的代码、描述、关联的 Jira 任务调用 LLM 进行自动代码审查检查代码规范、安全性、性能、测试覆盖率生成审查报告并测试和运维确认代码审查通过后自动合并 PR触发 GitHub Actions 的 CI/CD 流程CI/CD 流程如果失败自动查看日志排查问题调用 LLM 分析日志、调用依赖检查工具、调用基础设施监控 API生成修复建议并开发预发布验证智能体CI/CD 流程成功后自动部署到预发布环境自动读取验收标准调用 Postman API 运行接口测试调用 Playwright API 运行 E2E 测试自动生成测试报告测试通过后自动产品经理做用户验收测试UAT提供测试用例和操作指南生产部署与监控智能体UAT 通过后自动部署到生产环境使用蓝绿部署或金丝雀部署策略自动调用 New Relic API 监控性能、错误率、吞吐量、资源使用率自动调用 Typeform API 收集用户反馈自动设置阈值报警如果出现问题自动回滚金丝雀部署或暂停流量蓝绿部署自动生成问题报告并运维和开发迭代总结智能体迭代结束后自动收集所有数据Notion 需求文档、Figma 设计稿、Jira 进度表、GitHub PR 和代码、GitHub Actions 日志、Postman/Playwright 测试报告、New Relic 性能数据、Typeform 用户反馈自动生成一份 Confluence 上的迭代总结报告包括迭代目标达成情况、进度分析、质量分析、性能分析、用户反馈分析、问题复盘、改进建议整个流程的所有数据和操作都可追溯、可审计、可监控人类可以在任何环节干预——比如修改需求文档、否决设计稿、调整任务分配、拒绝自动代码审查的结果、暂停生产部署系统可以持续学习和优化——比如根据人类的干预调整需求分析的逻辑、根据代码审查的反馈调整代码规范的检查规则、根据测试失败的情况调整测试用例的生成策略。0.3 问题解决AI Agent Harness Engineering 的「四大支柱」要构建这样的「完美自动化工作流」我们需要掌握 AAH Engineering 的「四大支柱」支柱一AI Agent 的核心架构设计——包括 Agent 的感知层、推理层、行动层、记忆层、评估层和优化层支柱二多 Agent 协作的流程编排——包括 Agent 的任务分配、通信机制、状态管理、冲突解决和容错机制支柱三Agent 与现有工具链的深度集成——包括通用工具调用框架、API 封装、UI 自动化、数据模型转换支柱四Agent 的训练、部署、监控和维护——包括 Agent 的 Prompt 工程、微调Fine-tuning、RAG检索增强生成、部署架构、监控指标、日志审计和故障排查。0.4 边界与外延AAH Engineering 能做什么不能做什么0.4.1 能做什么适用场景AAH Engineering 最适合处理端到端、跨工具、有一定不确定性但有明确目标和验收标准的复杂工作流任务比如软件开发全生命周期需求分析、任务拆解、代码开发、代码审查、测试、部署、监控、迭代总结内容创作与运营选题策划、内容生成、内容编辑、SEO 优化、多平台发布、数据监控、用户回复客户服务与支持客户咨询解答、工单分配、工单处理、问题排查、解决方案生成、客户满意度调查、工单总结数据分析与报告数据采集、数据清洗、数据可视化、数据分析、报告生成、报告分发项目管理与协作项目规划、任务分配、进度跟踪、风险评估、沟通协调、文档管理金融与保险贷款审批、保险理赔、风险评估、投资分析、客户服务。0.4.2 不能做什么边界限制AAH Engineering 不是万能的它有以下几个明确的边界限制需要明确的目标和验收标准如果任务的目标和验收标准不明确比如「创造一个革命性的产品」Agent 无法制定计划和评估结果需要稳定的工具和环境如果工具或环境经常变化比如一个刚上线的 API 每天都在改接口Agent 的工具调用会经常失败维护成本会很高需要人类的决策和创新Agent 只能在现有的知识和规则下工作无法做出突破性的创新比如发明一种新的编程语言也无法做出涉及道德、法律、情感的重大决策比如解雇员工、批准一个高风险的贷款有幻觉和局限性LLM 本身有幻觉问题Agent 的推理能力和工具调用能力也受限于 LLM 的能力和工具的可用性需要持续的投入和维护构建和维护 AAH 系统需要投入大量的时间、金钱和人力——包括 Prompt 工程、工具集成、流程编排、训练优化、监控维护等。第一章AI Agent 的核心架构设计——从「大脑」到「全身」1.1 核心概念什么是一个「合格的 AI Agent」在 AAH Engineering 中一个合格的 AI Agent必须具备以下六个核心能力感知能力Perception能够感知外部环境包括用户输入、工具状态、数据变化等和内部状态包括记忆、任务进度、能量消耗等推理能力Reasoning能够根据感知到的信息和记忆制定合理的计划做出正确的决策行动能力Action能够执行计划中的行动包括调用工具、与用户交互、修改内部状态等记忆能力Memory能够存储和检索感知到的信息、执行过的行动、做出过的决策、学到的知识等评估能力Evaluation能够评估行动的结果是否达到了预期的目标如果没有能够分析原因优化能力Optimization能够根据评估的结果持续优化自己的推理逻辑、行动策略和记忆管理方式。为了实现这六个核心能力我们需要设计一个模块化、可扩展、可配置的 AI Agent 核心架构——目前业界最流行的架构是由斯坦福大学提出的**「生成式智能体Generative Agents」架构和由 OpenAI 提出的「函数调用Function Calling架构」的结合体我们称之为「AAH 标准 Agent 架构」**。注由于篇幅要求为每个章节大于10000字后续章节将在接下来的内容中继续展开包括但不限于AAH标准Agent架构的详细讲解、各模块的功能和实现、多Agent协作的流程编排、工具链集成、项目实战、最佳实践等内容。
