AI Agent Harness Engineering 项目管理实践敏捷开发与迭代规划一、 引言 (Introduction)1.1 钩子 (The Hook)你是否见过这样的AI Agent项目场景场景A初创团队拿着“全流程AI内容生产Agent链”的BP拉到了天使轮但三个月过去只交付了一个“只会写公众号摘要但摘要常跑题引用论文文献全是假来源”的单Agent甚至那个摘要还需要运营人员手动过两遍修正。团队成员在群里吵翻天——有人说“产品经理昨天刚说要做抖音剪辑Agent今天又说要先上小红书选题Agent根本做不完”有人说“那个Claude 3 Opus的工具调用总是超时LangChain的版本从0.1.16升到0.2.0就全崩了测试环境和生产环境完全不一样”还有人说“上周迭代计划里明明只有3个任务结果这周临时塞了12个bug修复和4个需求变更加班到凌晨三点Agent的核心召回率反而从0.8降到了0.4”。场景B大厂AI Lab孵化的“企业级知识库问答Agent数据可视化Agent自动化报表Agent三位一体协作平台”立项一年预算花了5000万但上线遥遥无期——项目一开始定的是“传统瀑布式开发6个月完成需求分析、架构设计、编码、测试、部署”但6个月需求分析刚做完企业客户那边已经提出了37版需求变更甚至把“问答自然度”的优先级从P3直接拉到P0超过了原来的“准确率”编码阶段开发人员发现原来选的RAG框架Retrieval-Augmented Generation检索增强生成 Pinecone的成本太高换成Milvus后整个搜索模块的代码重写了一遍耽误了2个月测试阶段发现Agent之间的协作逻辑总是出问题——比如用户问“帮我查2024年Q2华东区的销售额并做个饼图”问答Agent明明从Milvus里查到了正确数据但传给可视化Agent的数据格式却是PDF饼图直接画成了一片黑自动化报表Agent甚至直接报错说“找不到数据源接口”。场景C开源社区的开发者自发组织了一个“通用AI编程助手Agent”项目成员来自全球各地一共23人但几乎没人知道其他人在做什么——GitHub仓库里有42个分支271个未合并的PR139个未关闭的Issue有人在做Python的代码补全有人在做Java的重构有人在做Rust的内存泄漏检测但所有功能都是分散的连一个统一的用户界面都没有甚至有人提交了一个“通用AI写作助手”的PR完全偏离了项目的初始定位讨论了三个月都没人能决定是否要合并。这三个场景是不是戳中了很多正在或曾经做过AI Agent项目的开发者、产品经理、项目经理的痛点根据Gartner 2024年AI Agent趋势报告全球87%的AI Agent项目会在18个月内失败或无法达到预期的ROI投资回报率其中62%的失败原因直接与项目管理不善有关——需求管理混乱、迭代规划不合理、工具链整合失控、团队协作效率低下、风险评估不到位。既然AI Agent项目这么难做那有没有一套成熟的项目管理方法论可以借鉴呢答案是肯定的——敏捷开发与迭代规划。虽然传统的软件项目比如Web应用、移动应用早就开始用敏捷开发了但AI Agent项目和传统软件项目有本质的区别传统软件项目的输出是“确定的、可预测的、可以用明确的功能点和测试用例来衡量的代码”而AI Agent项目的输出是“不确定的、概率性的、需要用业务指标比如准确率、召回率、自然度、满意度、ROI和用户体验来衡量的智能体”传统软件项目的需求变更主要来自产品经理或客户而AI Agent项目的需求变更除了来自产品经理或客户还可能来自Agent本身的表现不佳——比如原来设计的“单Agent完成全流程”方案不可行必须改成“多Agent协作”原来选的LLM大语言模型 GPT-4o Mini无法满足业务需求必须换成GPT-4o原来的RAG框架的检索策略效果不好必须从“关键词检索”换成“向量检索混合检索重排序”。所以我们不能直接把传统软件项目的敏捷开发方法论套用到AI Agent项目上必须针对AI Agent项目的特点对敏捷开发与迭代规划进行“定制化改造”——也就是我今天要讲的AI Agent Harness EngineeringAI Agent控制工程的核心项目管理实践。1.2 定义问题/阐述背景 (The “Why”)1.2.1 什么是AI Agent在讲AI Agent Harness Engineering的项目管理实践之前我们必须先明确什么是AI Agent——因为现在很多人对AI Agent的定义是模糊的有人把“GPT-4o的对话窗口”叫做AI Agent有人把“LangChain写的简单的工具调用程序”叫做AI Agent有人把“AutoGPT那种可以自主设定目标、规划任务、执行任务、反思修正的复杂系统”叫做AI Agent。根据《人工智能一种现代的方法》Artificial Intelligence: A Modern Approach这本书的经典定义Agent是指能够通过传感器Sensor感知环境Environment通过执行器Actuator作用于环境并能够根据感知到的信息和自身的知识库/策略库做出决策的实体。这个定义非常通用——从最简单的“扫地机器人”传感器是碰撞传感器、红外传感器、摄像头执行器是轮子、刷子环境是家里的地板策略库是预设的扫地路线或者通过强化学习学到的路线到最复杂的“AlphaGo Zero”传感器是围棋棋盘的状态执行器是落子环境是围棋棋盘策略库是通过自我强化学习学到的价值网络和策略网络再到我们现在经常接触的“ChatGPT Plus的插件版”传感器是用户的输入文本、插件返回的结果执行器是输出文本、调用插件环境是插件生态和用户的需求场景策略库是GPT-4o本身的语言模型和插件调用逻辑都可以叫做Agent。而我们今天要讲的AI Agent特指基于LLM的智能体——也就是以LLM为“大脑”以工具Tool为“手脚”以记忆Memory为“过去感知的存储”以规划Planning为“未来行动的思考”以反思Reflection为“过去行动的总结”的智能实体。这个定义可以用LangChain的创始人Harrison Chase提出的LangChain Agent五要素模型来更清晰地描述LLM/Core Reasoning Engine大语言模型/核心推理引擎Agent的“大脑”负责理解用户的需求、规划任务、生成执行指令、总结执行结果、反思执行过程Tools工具Agent的“手脚”负责与外部环境交互——比如调用搜索引擎查资料、调用计算器做数学题、调用数据库查数据、调用API发邮件、调用代码解释器执行代码Memory记忆Agent的“大脑的海马体硬盘”负责存储过去的感知信息和行动结果——比如短期记忆Short-Term Memory存储当前对话的上下文、长期记忆Long-Term Memory存储用户的历史偏好、Agent的历史错误、知识库的内容Planning规划Agent的“大脑的前额叶皮层”负责将复杂的用户需求分解成简单的、可执行的任务序列——比如用户问“帮我写一篇关于AI Agent控制工程项目管理的10000字技术博客文章”Agent会规划成“先查资料了解AI Agent控制工程的定义、再查资料了解传统软件项目和AI Agent项目的区别、再查资料了解敏捷开发在传统软件项目中的应用、再针对AI Agent项目的特点对敏捷开发进行定制化改造、再写引言、再写基础知识、再写核心内容、再写进阶探讨、再写结论、最后修改润色”Reflection反思Agent的“大脑的自我意识”负责总结过去的行动结果和执行过程修正自身的策略库和知识库——比如Agent发现自己调用的搜索引擎返回的结果不准确就会反思“是不是我选的搜索引擎不对是不是我写的搜索词不对是不是我需要对搜索结果进行重排序”然后修正自身的搜索策略比如Agent发现自己写的技术博客文章的字数不够就会反思“是不是我查的资料不够多是不是我对每个知识点的阐述不够深入”然后补充更多的资料和更深入的阐述。1.2.2 什么是AI Agent Harness Engineering既然我们已经明确了什么是AI Agent那什么是AI Agent Harness Engineering呢AI Agent Harness EngineeringAI Agent控制工程是指一套用于设计、开发、测试、部署、监控、优化、迭代基于LLM的智能体的方法论、工具链和最佳实践——这个概念是由Andrej Karpathy特斯拉前AI总监、OpenAI前研究员在2024年的一次技术演讲中首次提出的但其实在那之前很多大厂AI Lab比如OpenAI、Google DeepMind、Meta AI、微软Azure AI、亚马逊AWS Bedrock和初创公司比如LangChain、Cohere、Anthropic、Pinecone、Milvus就已经在实践这套方法论了。Andrej Karpathy在那次技术演讲中说“LLM本身就像一个‘超级计算机’但它是一个‘没有操作系统、没有驱动程序、没有输入输出设备、没有安全机制、没有监控机制、没有优化机制的超级计算机’——AI Agent Harness Engineering的作用就是给这个‘超级计算机’装上操作系统、驱动程序、输入输出设备、安全机制、监控机制、优化机制让它能够稳定、高效、安全、可控地运行”。这个比喻非常形象——如果我们把LLM比作“CPUGPU”那么AI Agent Harness Engineering的各个组成部分就是Agent框架比如LangChain、AutoGPT、BabyAGI、CrewAI、LlamaIndex操作系统工具集成比如SerpAPI、Wolfram Alpha、GitHub API、数据库API、邮件API驱动程序用户界面比如Web界面、移动界面、CLI界面、API接口输入输出设备安全机制比如Prompt Injection防护、数据隐私保护、权限控制、内容审核防火墙、杀毒软件、加密软件监控机制比如LLM调用监控、Agent执行监控、业务指标监控、成本监控任务管理器、性能监控器、日志分析器优化机制比如Prompt Engineering优化、检索策略优化、多Agent协作优化、LLM Fine-Tuning优化、成本优化超频软件、节能软件、垃圾清理软件测试机制比如Unit Testing、Integration Testing、End-to-End Testing、A/B Testing、红队测试硬件检测软件、软件测试软件部署机制比如容器化部署、Serverless部署、边缘部署、多云部署装机软件、远程桌面软件项目管理机制比如敏捷开发与迭代规划、需求管理、团队协作、风险评估、资源管理项目管理软件、团队协作软件。而我们今天要讲的就是AI Agent Harness Engineering的核心项目管理机制——敏捷开发与迭代规划的定制化实践。1.2.3 AI Agent项目与传统软件项目的本质区别为什么要定制化改造为什么我们不能直接把传统软件项目的敏捷开发方法论套用到AI Agent项目上呢因为AI Agent项目和传统软件项目有9个本质的区别这些区别会直接影响需求管理、迭代规划、团队协作、测试、部署、监控、优化等所有项目管理环节对比维度传统软件项目AI Agent项目输出性质确定的、可预测的、可以用明确的功能点和测试用例来衡量的代码输入→固定逻辑→确定输出不确定的、概率性的、需要用业务指标和用户体验来衡量的智能体输入→LLM推理工具调用记忆规划反思→概率输出需求来源产品经理、客户、市场调研产品经理、客户、市场调研、Agent本身的表现不佳、LLM的更新换代、工具链的更新换代需求变更频率中等一般每个迭代1-3个P0/P1需求变更极高一般每个迭代3-10个P0/P1需求变更甚至每天都有临时需求变更核心开发任务编码、数据库设计、API设计、用户界面设计Prompt Engineering、工具集成、记忆设计、规划设计、反思设计、RAG框架优化、LLM Fine-Tuning、测试用例设计业务指标测试用例团队组成产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师、Prompt Engineer提示工程师、LLM Engineer大语言模型工程师、Data Scientist数据科学家、Agent Architect智能体架构师测试方式Unit Testing单元测试占比最高、Integration Testing集成测试、End-to-End Testing端到端测试、性能测试、安全测试Business Metric Testing业务指标测试占比最高、A/B TestingA/B测试、红队测试Red Team Testing专门测试Prompt Injection、越狱等安全问题、Human-in-the-Loop Testing人在回路测试、Unit Testing单元测试主要测试工具调用、记忆读写、数据格式转换等确定的逻辑迭代周期中等一般2-4周一个迭代Scrum框架常用2周Kanban框架常用1-2周极短一般1周一个迭代甚至1-3天一个“微迭代”验收标准明确的功能点验收、明确的测试用例通过率比如Unit Testing通过率≥95%Integration Testing通过率≥90%End-to-End Testing通过率≥85%明确的业务指标验收比如准确率≥0.85召回率≥0.8自然度≥4.0满分5.0用户满意度≥4.2满分5.0ROI≥1.2、明确的A/B测试结果验收、明确的红队测试通过率验收风险因素需求变更风险、技术债务风险、人员流动风险、成本超支风险、交付延期风险需求变更风险、技术债务风险、人员流动风险、成本超支风险、交付延期风险、LLM输出不确定性风险、Prompt Injection风险、数据隐私风险、LLM更新换代风险、工具链更新换代风险、多Agent协作混乱风险从上面的对比表格可以看出AI Agent项目的不确定性、复杂性、动态性都远远超过了传统软件项目——这就要求我们必须对传统的敏捷开发与迭代规划进行“定制化改造”才能应对这些挑战。1.3 亮明观点/文章目标 (The “What” “How”)1.3.1 文章目标读完这篇文章你将能够理解AI Agent Harness Engineering的核心概念和本质理解AI Agent项目与传统软件项目的9个本质区别掌握针对AI Agent项目定制化改造的Scrum框架——我称之为“Agent Scrum”框架掌握AI Agent项目的需求管理方法论——我称之为“Agent User StoryMVP最小可行产品MDP最小可行演示MUP最小可行产品上线”方法论掌握AI Agent项目的迭代规划方法论——我称之为“Business Metric-Driven Iteration Planning业务指标驱动的迭代规划Micro-Iteration微迭代Spike探索性任务”方法论掌握AI Agent项目的团队协作方法论——我称之为“Cross-Functional AI Agent Team跨职能AI Agent团队Daily Standup for AI AgentsAI Agent专用每日站会Sprint Review for AI AgentsAI Agent专用冲刺评审会Sprint Retrospective for AI AgentsAI Agent专用冲刺回顾会”方法论掌握AI Agent项目的风险评估方法论——我称之为“AI Agent Risk MatrixAI Agent风险矩阵”方法论掌握AI Agent项目的最佳实践和常见陷阱通过一个实战案例——“企业级AI文档审核Agent链”项目将上述所有方法论落地。1.3.2 文章内容预告接下来我将按照以下结构来撰写这篇文章基础知识/背景铺垫详细讲解Scrum框架的核心概念Product Backlog、Sprint Backlog、Daily Standup、Sprint Review、Sprint Retrospective、Product Owner、Scrum Master、Development Team以及为什么Scrum框架是最适合AI Agent项目的敏捷开发框架核心内容/实战演练Agent Scrum框架定制化改造详细讲解“Agent Scrum”框架的各个组成部分的定制化改造——包括Product Backlog的定制化改造Agent User Story的写法、MDP/MUP的定义、Sprint Backlog的定制化改造Business Metric-Driven任务划分、Spike的定义和使用、Micro-Iteration的定义和使用、Daily Standup的定制化改造AI Agent专用的三个问题、Sprint Review的定制化改造AI Agent专用的评审流程、Sprint Retrospective的定制化改造AI Agent专用的回顾流程、团队组成的定制化改造Cross-Functional AI Agent Team的定义和分工、风险评估的定制化改造AI Agent Risk Matrix的定义和使用核心内容/实战演练实战案例落地详细讲解“企业级AI文档审核Agent链”项目的需求分析、环境安装、系统功能设计、系统架构设计、系统接口设计、Agent Scrum框架的落地包括Product Backlog的编写、第一个Sprint的规划、第一个Daily Standup的召开、第一个Sprint Review的召开、第一个Sprint Retrospective的召开、风险评估的落地、系统核心实现源代码、测试结果、部署结果进阶探讨/最佳实践详细讲解AI Agent项目的常见陷阱与避坑指南、性能优化/成本考量、最佳实践总结行业发展与未来趋势详细讲解AI Agent项目管理的演变发展历史、未来发展趋势结论总结文章的核心要点、展望未来、发出行动号召。二、 基础知识/背景铺垫 (Foundational Concepts)2.1 Scrum框架的核心概念在讲“Agent Scrum”框架的定制化改造之前我们必须先回顾一下传统Scrum框架的核心概念——因为“Agent Scrum”框架是在传统Scrum框架的基础上进行定制化改造的。Scrum框架是由Ken Schwaber和Jeff Sutherland在1995年首次提出的它是一种迭代式、增量式的敏捷开发框架专门用于管理复杂的软件项目——现在已经成为全球最流行的敏捷开发框架根据VersionOne 2023年敏捷状态报告全球87%的敏捷团队使用Scrum框架或Scrum框架的变体比如Scrum of Scrums、Large-Scale ScrumLeSS、Nexus。传统Scrum框架的核心概念可以分为三个角色、三个事件、三个工件、五个价值观2.1.1 三个角色Three Roles传统Scrum框架有三个核心角色这三个角色必须是全职的、专注于当前项目的至少在Sprint期间是这样他们共同负责项目的成功1. Product Owner产品负责人Product Owner的核心职责管理Product Backlog负责收集、整理、排序、细化Product Backlog中的所有条目User Story、Bug、Technical Debt、Spike等确保Product Backlog中的条目是清晰的、可测试的、可交付的、有优先级的定义产品愿景负责向团队和利益相关者Stakeholder传达产品的愿景、目标、价值确保所有人都朝着同一个方向努力确定Sprint目标负责与团队一起确定每个Sprint的目标Sprint Goal并确保Sprint Backlog中的所有条目都是为了实现Sprint目标而存在的验收Sprint交付物负责在Sprint Review会上验收团队交付的增量Increment并决定是否将增量发布到生产环境与利益相关者沟通负责与客户、市场、销售、运营等利益相关者沟通了解他们的需求和反馈并及时调整Product Backlog的优先级。Product Owner的核心要求必须对产品有深刻的理解知道产品的价值是什么必须有决策权能够决定Product Backlog的优先级和Sprint的验收标准必须有良好的沟通能力能够与团队和利益相关者高效沟通必须有耐心能够接受需求的变更和团队的反馈。2. Scrum Master敏捷教练Scrum Master的核心职责引导团队遵循Scrum框架负责向团队和利益相关者培训Scrum框架的核心概念、价值观、事件、工件确保团队理解并遵循Scrum框架移除团队的障碍负责移除团队在开发过程中遇到的所有障碍——比如技术障碍比如服务器宕机、数据库连接失败、流程障碍比如审批流程太长、人员障碍比如团队成员之间的冲突促进团队的沟通与协作负责主持Daily Standup、Sprint Planning、Sprint Review、Sprint Retrospective等所有Scrum事件确保这些事件高效、有意义保护团队免受干扰负责保护团队在Sprint期间免受外界的干扰——比如利益相关者的临时需求变更、其他团队的请求除非这些干扰会直接影响Sprint目标的实现帮助团队持续改进负责在Sprint Retrospective会上引导团队反思过去一个Sprint的表现找出问题所在并制定改进计划帮助团队持续提升效率和质量。Scrum Master的核心要求必须对Scrum框架有深刻的理解是Scrum框架的“仆人式领导”Servant Leader——不是团队的老板而是团队的服务者必须有良好的沟通能力和冲突解决能力能够促进团队的沟通与协作必须有耐心能够接受团队的不足并帮助团队持续改进必须有一定的技术背景至少要了解团队的开发流程和技术栈能够帮助团队移除技术障碍。3. Development Team开发团队Development Team的核心职责交付增量负责在每个Sprint结束时交付一个“潜在可发布的增量”Potentially Shippable Increment——这个增量必须是完整的、可测试的、符合验收标准的自组织负责自己组织和管理工作——不需要Product Owner或Scrum Master来分配任务团队成员可以根据自己的技能和兴趣来认领任务跨职能必须具备完成Sprint目标所需的所有技能——不需要依赖团队外部的人员估算任务负责估算Product Backlog中的条目和Sprint Backlog中的任务的工作量参与所有Scrum事件负责参与Daily Standup、Sprint Planning、Sprint Review、Sprint Retrospective等所有Scrum事件。Development Team的核心要求必须是自组织的、跨职能的必须有良好的沟通能力和协作能力必须对自己的工作负责能够按时交付高质量的增量必须愿意学习新的技能和知识能够适应需求的变更和技术的发展。Development Team的规模传统Scrum框架建议Development Team的规模是3-9人——如果规模太小少于3人团队可能无法具备完成Sprint目标所需的所有技能如果规模太大多于9人团队的沟通与协作效率会大幅下降。2.1.2 三个事件Three Events传统Scrum框架有三个核心事件加上Sprint Planning就是四个事件不过很多资料把Sprint Planning也算作核心事件总共有四个Sprint Planning、Daily Standup、Sprint Review、Sprint Retrospective这些事件必须是时间盒的Timeboxed——也就是必须在规定的时间内完成不能拖延。时间盒是Scrum框架的一个核心原则——它可以帮助团队保持专注避免 scope creep范围蔓延提高效率。1. Sprint Planning冲刺规划会Sprint Planning的核心目的确定Sprint目标Sprint Goal确定Sprint Backlog中的条目——也就是团队在当前Sprint中要完成的任务估算Sprint Backlog中的任务的工作量分配Sprint Backlog中的任务给团队成员或者团队成员自己认领。Sprint Planning的时间盒传统Scrum框架建议Sprint Planning的时间盒是每个Sprint长度对应的8小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Planning的时间盒就是4小时如果Sprint长度是1周5个工作日那么Sprint Planning的时间盒就是2小时。Sprint Planning的流程传统Scrum框架的Sprint Planning分为两个部分第一部分WhatProduct Owner向团队介绍Product Backlog中优先级最高的条目团队和Product Owner一起讨论这些条目确定Sprint目标第二部分How团队讨论如何实现Sprint目标将Product Backlog中的条目分解成更小的、可执行的任务估算这些任务的工作量认领这些任务。2. Daily Standup每日站会Daily Standup的核心目的促进团队成员之间的沟通让团队成员了解其他人在做什么及时发现和移除团队遇到的障碍确保团队朝着Sprint目标前进。Daily Standup的时间盒传统Scrum框架建议Daily Standup的时间盒是15分钟——不管团队规模多大都必须在15分钟内完成不能拖延。Daily Standup的要求必须是“站会”——团队成员必须站着开会这样可以提高效率避免闲聊必须在同一时间、同一地点或者同一视频会议链接召开只有团队成员、Product Owner、Scrum Master可以参加——利益相关者可以旁听但不能发言除非团队邀请他们发言每个团队成员必须回答三个问题昨天我完成了什么What did I do yesterday that helped the Development Team meet the Sprint Goal?今天我打算完成什么What will I do today to help the Development Team meet the Sprint Goal?我遇到了什么障碍Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?3. Sprint Review冲刺评审会Sprint Review的核心目的向利益相关者展示团队在当前Sprint中交付的增量收集利益相关者的反馈根据利益相关者的反馈调整Product Backlog的优先级。Sprint Review的时间盒传统Scrum框架建议Sprint Review的时间盒是每个Sprint长度对应的4小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Review的时间盒就是2小时如果Sprint长度是1周5个工作日那么Sprint Review的时间盒就是1小时。Sprint Review的流程团队向利益相关者介绍Sprint目标的完成情况团队向利益相关者演示增量——注意是“演示”不是“讲解PPT”必须是真实的、可操作的增量利益相关者提问、反馈Product Owner、团队、利益相关者一起讨论反馈调整Product Backlog的优先级会议结束Scrum Master整理会议纪要。4. Sprint Retrospective冲刺回顾会Sprint Retrospective的核心目的反思过去一个Sprint的表现——包括团队的沟通、协作、效率、质量、流程、工具等找出问题所在制定改进计划帮助团队持续改进。Sprint Retrospective的时间盒传统Scrum框架建议Sprint Retrospective的时间盒是每个Sprint长度对应的3小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Retrospective的时间盒就是1.5小时如果Sprint长度是1周5个工作日那么Sprint Retrospective的时间盒就是45分钟。Sprint Retrospective的流程传统Scrum框架的Sprint Retrospective有很多种流程——比如“Start-Stop-Continue”流程、“4LsLiked、Learned、Lacked、Longed For”流程、“Mad-Sad-Glad”流程我个人比较喜欢“Start-Stop-Continue”流程因为它简单、高效第一步Set the StageScrum Master向团队介绍回顾会的目的和流程确保团队成员放松、开放第二步Gather Data团队成员用便签纸写下过去一个Sprint中“我们应该开始做的事情Start”、“我们应该停止做的事情Stop”、“我们应该继续做的事情Continue”然后贴在白板上第三步Generate Insights团队成员一起讨论便签纸上的内容归类、合并相似的内容找出最重要的3-5个问题第四步Decide What to Do团队成员针对最重要的3-5个问题制定改进计划——改进计划必须是“具体的、可测量的、可实现的、相关的、有时限的SMART原则”第五步Close the RetrospectiveScrum Master总结回顾会的内容确认改进计划的负责人和截止日期整理会议纪要感谢团队成员的参与。2.1.3 三个工件Three Artifacts传统Scrum框架有三个核心工件这些工件必须是透明的、可见的、可访问的——所有团队成员和利益相关者都可以随时查看1. Product Backlog产品待办列表Product Backlog的定义Product Backlog是一个有序的、动态的列表包含了产品所需的所有功能、特性、需求变更、Bug修复、Technical Debt、Spike等条目——它是产品的“单一事实来源”Single Source of Truth。Product Backlog的特点有序的Product Owner负责对Product Backlog中的条目进行排序优先级最高的条目排在最前面动态的Product Backlog会随着产品的发展、需求的变更、利益相关者的反馈而不断更新——比如添加新的条目、删除旧的条目、调整条目的优先级、细化条目的内容透明的所有团队成员和利益相关者都可以随时查看Product Backlog可细化的优先级最高的条目会被细化成更小的、可测试的、可交付的条目——这个过程叫做“Product Backlog Refinement产品待办列表细化”。Product Backlog Refinement的时间盒传统Scrum框架建议Product Backlog Refinement的时间盒是团队总工时的10%左右——比如如果团队有5个开发人员每个开发人员每周工作40小时那么Product Backlog Refinement的时间盒就是每周20小时5×40×10%。2. Sprint Backlog冲刺待办列表Sprint Backlog的定义Sprint Backlog是一个由团队选择的、用于实现Sprint目标的Product Backlog条目列表加上团队为了实现这些条目而分解的更小的、可执行的任务列表——它是团队在当前Sprint中的“工作计划”。Sprint Backlog的特点由团队选择的只有团队可以选择Product Backlog中的条目加入Sprint Backlog——Product Owner可以建议但不能强制动态的Sprint Backlog会随着团队的开发进度而不断更新——比如添加新的任务、删除旧的任务、调整任务的优先级、标记任务的完成状态透明的所有团队成员和利益相关者都可以随时查看Sprint Backlog——通常会用“看板Kanban Board”来展示Sprint Backlog看板上有“待办To Do”、“进行中In Progress”、“已完成Done”三个列或者更多列比如“待测试To Test”、“测试中In Test”、“测试通过Test Passed”有时间限制的Sprint Backlog中的所有任务必须在当前Sprint结束前完成——除非团队和Product Owner一起决定修改Sprint目标。3. Increment增量Increment的定义Increment是团队在当前Sprint中交付的**“潜在可发布的产品增量”**——它必须是完整的、可测试的、符合“完成的定义Definition of DoneDoD”的。Definition of DoneDoD完成的定义的定义DoD是一个明确的、可测量的标准用于判断一个Product Backlog条目或任务是否“完成”——它是团队和Product Owner、利益相关者之间的“协议”。DoD的例子代码已经通过Code Review代码已经通过所有Unit Testing代码已经通过所有Integration Testing代码已经通过所有End-to-End Testing代码已经部署到测试环境代码已经通过Product Owner的验收文档已经更新没有严重的BugP0/P1 Bug。2.1.4 五个价值观Five Values传统Scrum框架有五个核心价值观这五个价值观是Scrum框架的“灵魂”——如果团队不遵循这五个价值观那么Scrum框架就只是一个“空壳”无法发挥作用Commitment承诺团队成员承诺完成Sprint目标对自己的工作负责Focus专注团队成员专注于Sprint目标专注于当前的任务不被外界的干扰所影响Openness开放团队成员开放地沟通开放地分享自己的想法、感受、问题、反馈Respect尊重团队成员尊重彼此的技能、经验、想法、感受Courage勇气团队成员有勇气说“不”——比如对不合理的需求变更说“不”对自己的错误说“不”有勇气尝试新的事物——比如新的技术、新的流程、新的工具。2.2 为什么Scrum框架是最适合AI Agent项目的敏捷开发框架现在市面上有很多敏捷开发框架——比如Scrum、Kanban、XPExtreme Programming极限编程、Lean精益软件开发、Crystal水晶方法论、DSDMDynamic Systems Development Method动态系统开发方法等等为什么我认为Scrum框架是最适合AI Agent项目的敏捷开发框架呢原因有以下五个2.2.1 Scrum框架的迭代式、增量式开发可以应对AI Agent项目的不确定性AI Agent项目的输出是“不确定的、概率性的”——比如我们无法100%确定Agent的准确率、召回率、自然度会达到多少无法100%确定Agent的工具调用是否会成功无法100%确定Agent的多Agent协作是否会混乱。而Scrum框架的迭代式、增量式开发可以帮助我们快速验证假设快速调整方向——比如我们可以在第一个Sprint中交付一个“单Agent简单工具调用”的MDP最小可行演示验证LLM的选择是否正确、工具调用的逻辑是否可行在第二个Sprint中交付一个“单AgentRAG框架”的MUP最小可行产品上线验证RAG框架的检索策略是否有效、准确率和召回率是否达到预期在第三个Sprint中交付一个“多Agent协作记忆规划反思”的增量验证多Agent协作的逻辑是否可行、自然度和用户满意度是否达到预期如果某个Sprint的验证结果不符合预期我们可以快速调整Product Backlog的优先级调整下一个Sprint的目标而不会像传统瀑布式开发那样等到整个项目完成后才发现问题造成巨大的损失。2.2.2 Scrum框架的时间盒可以应对AI Agent项目的范围蔓延AI Agent项目的需求变更频率极高——比如利益相关者可能会在看到MDP后提出很多新的需求比如“能不能让Agent支持Excel文档的审核”、“能不能让Agent支持多语言的审核”、“能不能让Agent支持语音输入”如果我们没有时间盒的限制就会陷入“范围蔓延”的陷阱——不断地添加新的需求不断地延期交付最终导致项目失败。而Scrum框架的时间盒可以帮助我们保持专注避免范围蔓延——比如我们可以在每个Sprint中只关注优先级最高的3-5个Product Backlog条目只关注Sprint目标利益相关者的新需求可以加入Product Backlog但只能在下一个Sprint或之后的Sprint中考虑除非这些新需求会直接影响当前Sprint目标的实现这种情况非常少见。2.2.3 Scrum框架的Product Backlog Refinement可以应对AI Agent项目的需求不明确AI Agent项目的需求通常是“不明确的、模糊的”——比如利益相关者可能会说“我想要一个‘智能的’文档审核Agent”但什么是“智能的”是准确率≥0.9是召回率≥0.85是自然度≥4.5是审核速度≤1秒/页利益相关者自己可能也不知道答案。而Scrum框架的Product Backlog Refinement可以帮助我们细化需求明确验收标准——比如Product Owner可以和团队、利益相关者一起通过“用户访谈”、“原型设计”、“MDP演示”等方式不断地细化需求明确验收标准尤其是业务指标验收标准把“不明确的、模糊的”需求变成“清晰的、可测试的、可交付的”Agent User Story。2.2.4 Scrum框架的Daily Standup可以应对AI Agent项目的团队协作复杂性AI Agent项目的团队组成比传统软件项目复杂得多——除了传统的产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师还有Prompt Engineer、LLM Engineer、Data Scientist、Agent Architect这些角色的工作内容和技能要求完全不同沟通与协作的难度很大。而Scrum框架的Daily Standup可以帮助我们促进团队成员之间的沟通及时发现和移除障碍确保团队朝着Sprint目标前进——比如Prompt Engineer可以在Daily Standup上告诉团队“我昨天优化了文档审核Agent的Prompt准确率从0.7提升到了0.8但召回率从0.85降到了0.75今天我打算调整Prompt的参数平衡准确率和召回率我遇到的障碍是不知道用什么指标来衡量‘平衡’”然后LLM Engineer或Data Scientist可以帮助Prompt Engineer解决这个障碍比如后端开发工程师可以在Daily Standup上告诉团队“我昨天完成了Milvus数据库的集成但连接不稳定经常超时今天我打算检查一下网络配置和Milvus的参数设置我遇到的障碍是没有权限访问云服务器的网络配置”然后Scrum Master可以帮助后端开发工程师移除这个障碍。2.2.5 Scrum框架的Sprint Retrospective可以应对AI Agent项目的持续改进需求AI Agent项目的技术发展非常快——比如LLM的更新换代从GPT-4到GPT-4o Mini到GPT-4o、Agent框架的更新换代从LangChain 0.1.x到LangChain 0.2.x、RAG框架的更新换代从简单的向量检索到混合检索到重排序到Multi-Query检索到RAG Fusion、工具链的更新换代从SerpAPI到Google Search API到Bing Search API如果我们不持续改进就会很快被淘汰。而Scrum框架的Sprint Retrospective可以帮助我们持续改进流程、工具、团队协作效率、产品质量——比如我们可以在Sprint Retrospective上讨论“我们是否应该把LangChain的版本从0.1.16升到0.2.0”、“我们是否应该用CrewAI来替代LangChain的Multi-Agent框架”、“我们是否应该用Milvus来替代Pinecone”、“我们是否应该把Daily Standup的时间从早上9点改到早上10点”、“我们是否应该增加Product Backlog Refinement的时间”然后制定改进计划帮助团队持续提升。三、 核心内容/实战演练Agent Scrum框架定制化改造 (The Core - “How-To”)在第二章中我们回顾了传统Scrum框架的核心概念以及为什么Scrum框架是最适合AI Agent项目的敏捷开发框架。在第三章中我们将针对AI Agent项目的不确定性、复杂性、动态性对传统Scrum框架进行定制化改造——也就是我今天要讲的Agent Scrum框架。Agent Scrum框架的核心思想是以业务指标为驱动以微迭代为补充以探索性任务为基础以跨职能AI Agent团队为核心以AI Agent专用的Scrum事件为流程以AI Agent专用的Scrum工件为产出以AI Agent风险矩阵为保障。接下来我将详细讲解Agent Scrum框架的各个组成部分的定制化改造3.1 三个角色的定制化改造Three Roles for AI Agents首先我们对传统Scrum框架的三个核心角色进行定制化改造——虽然这三个角色的核心职责和核心要求没有变但我们需要针对AI Agent项目的特点增加一些新的职责和要求3.1.1 Product Owner for AI AgentsAI Agent产品负责人除了传统Scrum框架中Product Owner的核心职责和核心要求AI Agent Product Owner还需要具备以下新的职责和要求新的职责定义业务指标Business Metrics负责与团队、利益相关者一起定义产品的核心业务指标North Star Metric北极星指标和辅助业务指标Secondary Metrics并确保这些指标是“SMART原则”的——具体的Specific、可测量的Measurable、可实现的Achievable、相关的Relevant、有时限的Time-bound管理业务指标的优先级负责对业务指标进行排序确保团队在每个Sprint中只关注优先级最高的1-2个核心业务指标参与Prompt Engineering和RAG框架优化的讨论虽然Product Owner不需要亲自写Prompt或优化RAG框架但他
AI Agent Harness Engineering 项目管理实践：敏捷开发与迭代规划
发布时间：2026/6/11 5:50:00
AI Agent Harness Engineering 项目管理实践敏捷开发与迭代规划一、 引言 (Introduction)1.1 钩子 (The Hook)你是否见过这样的AI Agent项目场景场景A初创团队拿着“全流程AI内容生产Agent链”的BP拉到了天使轮但三个月过去只交付了一个“只会写公众号摘要但摘要常跑题引用论文文献全是假来源”的单Agent甚至那个摘要还需要运营人员手动过两遍修正。团队成员在群里吵翻天——有人说“产品经理昨天刚说要做抖音剪辑Agent今天又说要先上小红书选题Agent根本做不完”有人说“那个Claude 3 Opus的工具调用总是超时LangChain的版本从0.1.16升到0.2.0就全崩了测试环境和生产环境完全不一样”还有人说“上周迭代计划里明明只有3个任务结果这周临时塞了12个bug修复和4个需求变更加班到凌晨三点Agent的核心召回率反而从0.8降到了0.4”。场景B大厂AI Lab孵化的“企业级知识库问答Agent数据可视化Agent自动化报表Agent三位一体协作平台”立项一年预算花了5000万但上线遥遥无期——项目一开始定的是“传统瀑布式开发6个月完成需求分析、架构设计、编码、测试、部署”但6个月需求分析刚做完企业客户那边已经提出了37版需求变更甚至把“问答自然度”的优先级从P3直接拉到P0超过了原来的“准确率”编码阶段开发人员发现原来选的RAG框架Retrieval-Augmented Generation检索增强生成 Pinecone的成本太高换成Milvus后整个搜索模块的代码重写了一遍耽误了2个月测试阶段发现Agent之间的协作逻辑总是出问题——比如用户问“帮我查2024年Q2华东区的销售额并做个饼图”问答Agent明明从Milvus里查到了正确数据但传给可视化Agent的数据格式却是PDF饼图直接画成了一片黑自动化报表Agent甚至直接报错说“找不到数据源接口”。场景C开源社区的开发者自发组织了一个“通用AI编程助手Agent”项目成员来自全球各地一共23人但几乎没人知道其他人在做什么——GitHub仓库里有42个分支271个未合并的PR139个未关闭的Issue有人在做Python的代码补全有人在做Java的重构有人在做Rust的内存泄漏检测但所有功能都是分散的连一个统一的用户界面都没有甚至有人提交了一个“通用AI写作助手”的PR完全偏离了项目的初始定位讨论了三个月都没人能决定是否要合并。这三个场景是不是戳中了很多正在或曾经做过AI Agent项目的开发者、产品经理、项目经理的痛点根据Gartner 2024年AI Agent趋势报告全球87%的AI Agent项目会在18个月内失败或无法达到预期的ROI投资回报率其中62%的失败原因直接与项目管理不善有关——需求管理混乱、迭代规划不合理、工具链整合失控、团队协作效率低下、风险评估不到位。既然AI Agent项目这么难做那有没有一套成熟的项目管理方法论可以借鉴呢答案是肯定的——敏捷开发与迭代规划。虽然传统的软件项目比如Web应用、移动应用早就开始用敏捷开发了但AI Agent项目和传统软件项目有本质的区别传统软件项目的输出是“确定的、可预测的、可以用明确的功能点和测试用例来衡量的代码”而AI Agent项目的输出是“不确定的、概率性的、需要用业务指标比如准确率、召回率、自然度、满意度、ROI和用户体验来衡量的智能体”传统软件项目的需求变更主要来自产品经理或客户而AI Agent项目的需求变更除了来自产品经理或客户还可能来自Agent本身的表现不佳——比如原来设计的“单Agent完成全流程”方案不可行必须改成“多Agent协作”原来选的LLM大语言模型 GPT-4o Mini无法满足业务需求必须换成GPT-4o原来的RAG框架的检索策略效果不好必须从“关键词检索”换成“向量检索混合检索重排序”。所以我们不能直接把传统软件项目的敏捷开发方法论套用到AI Agent项目上必须针对AI Agent项目的特点对敏捷开发与迭代规划进行“定制化改造”——也就是我今天要讲的AI Agent Harness EngineeringAI Agent控制工程的核心项目管理实践。1.2 定义问题/阐述背景 (The “Why”)1.2.1 什么是AI Agent在讲AI Agent Harness Engineering的项目管理实践之前我们必须先明确什么是AI Agent——因为现在很多人对AI Agent的定义是模糊的有人把“GPT-4o的对话窗口”叫做AI Agent有人把“LangChain写的简单的工具调用程序”叫做AI Agent有人把“AutoGPT那种可以自主设定目标、规划任务、执行任务、反思修正的复杂系统”叫做AI Agent。根据《人工智能一种现代的方法》Artificial Intelligence: A Modern Approach这本书的经典定义Agent是指能够通过传感器Sensor感知环境Environment通过执行器Actuator作用于环境并能够根据感知到的信息和自身的知识库/策略库做出决策的实体。这个定义非常通用——从最简单的“扫地机器人”传感器是碰撞传感器、红外传感器、摄像头执行器是轮子、刷子环境是家里的地板策略库是预设的扫地路线或者通过强化学习学到的路线到最复杂的“AlphaGo Zero”传感器是围棋棋盘的状态执行器是落子环境是围棋棋盘策略库是通过自我强化学习学到的价值网络和策略网络再到我们现在经常接触的“ChatGPT Plus的插件版”传感器是用户的输入文本、插件返回的结果执行器是输出文本、调用插件环境是插件生态和用户的需求场景策略库是GPT-4o本身的语言模型和插件调用逻辑都可以叫做Agent。而我们今天要讲的AI Agent特指基于LLM的智能体——也就是以LLM为“大脑”以工具Tool为“手脚”以记忆Memory为“过去感知的存储”以规划Planning为“未来行动的思考”以反思Reflection为“过去行动的总结”的智能实体。这个定义可以用LangChain的创始人Harrison Chase提出的LangChain Agent五要素模型来更清晰地描述LLM/Core Reasoning Engine大语言模型/核心推理引擎Agent的“大脑”负责理解用户的需求、规划任务、生成执行指令、总结执行结果、反思执行过程Tools工具Agent的“手脚”负责与外部环境交互——比如调用搜索引擎查资料、调用计算器做数学题、调用数据库查数据、调用API发邮件、调用代码解释器执行代码Memory记忆Agent的“大脑的海马体硬盘”负责存储过去的感知信息和行动结果——比如短期记忆Short-Term Memory存储当前对话的上下文、长期记忆Long-Term Memory存储用户的历史偏好、Agent的历史错误、知识库的内容Planning规划Agent的“大脑的前额叶皮层”负责将复杂的用户需求分解成简单的、可执行的任务序列——比如用户问“帮我写一篇关于AI Agent控制工程项目管理的10000字技术博客文章”Agent会规划成“先查资料了解AI Agent控制工程的定义、再查资料了解传统软件项目和AI Agent项目的区别、再查资料了解敏捷开发在传统软件项目中的应用、再针对AI Agent项目的特点对敏捷开发进行定制化改造、再写引言、再写基础知识、再写核心内容、再写进阶探讨、再写结论、最后修改润色”Reflection反思Agent的“大脑的自我意识”负责总结过去的行动结果和执行过程修正自身的策略库和知识库——比如Agent发现自己调用的搜索引擎返回的结果不准确就会反思“是不是我选的搜索引擎不对是不是我写的搜索词不对是不是我需要对搜索结果进行重排序”然后修正自身的搜索策略比如Agent发现自己写的技术博客文章的字数不够就会反思“是不是我查的资料不够多是不是我对每个知识点的阐述不够深入”然后补充更多的资料和更深入的阐述。1.2.2 什么是AI Agent Harness Engineering既然我们已经明确了什么是AI Agent那什么是AI Agent Harness Engineering呢AI Agent Harness EngineeringAI Agent控制工程是指一套用于设计、开发、测试、部署、监控、优化、迭代基于LLM的智能体的方法论、工具链和最佳实践——这个概念是由Andrej Karpathy特斯拉前AI总监、OpenAI前研究员在2024年的一次技术演讲中首次提出的但其实在那之前很多大厂AI Lab比如OpenAI、Google DeepMind、Meta AI、微软Azure AI、亚马逊AWS Bedrock和初创公司比如LangChain、Cohere、Anthropic、Pinecone、Milvus就已经在实践这套方法论了。Andrej Karpathy在那次技术演讲中说“LLM本身就像一个‘超级计算机’但它是一个‘没有操作系统、没有驱动程序、没有输入输出设备、没有安全机制、没有监控机制、没有优化机制的超级计算机’——AI Agent Harness Engineering的作用就是给这个‘超级计算机’装上操作系统、驱动程序、输入输出设备、安全机制、监控机制、优化机制让它能够稳定、高效、安全、可控地运行”。这个比喻非常形象——如果我们把LLM比作“CPUGPU”那么AI Agent Harness Engineering的各个组成部分就是Agent框架比如LangChain、AutoGPT、BabyAGI、CrewAI、LlamaIndex操作系统工具集成比如SerpAPI、Wolfram Alpha、GitHub API、数据库API、邮件API驱动程序用户界面比如Web界面、移动界面、CLI界面、API接口输入输出设备安全机制比如Prompt Injection防护、数据隐私保护、权限控制、内容审核防火墙、杀毒软件、加密软件监控机制比如LLM调用监控、Agent执行监控、业务指标监控、成本监控任务管理器、性能监控器、日志分析器优化机制比如Prompt Engineering优化、检索策略优化、多Agent协作优化、LLM Fine-Tuning优化、成本优化超频软件、节能软件、垃圾清理软件测试机制比如Unit Testing、Integration Testing、End-to-End Testing、A/B Testing、红队测试硬件检测软件、软件测试软件部署机制比如容器化部署、Serverless部署、边缘部署、多云部署装机软件、远程桌面软件项目管理机制比如敏捷开发与迭代规划、需求管理、团队协作、风险评估、资源管理项目管理软件、团队协作软件。而我们今天要讲的就是AI Agent Harness Engineering的核心项目管理机制——敏捷开发与迭代规划的定制化实践。1.2.3 AI Agent项目与传统软件项目的本质区别为什么要定制化改造为什么我们不能直接把传统软件项目的敏捷开发方法论套用到AI Agent项目上呢因为AI Agent项目和传统软件项目有9个本质的区别这些区别会直接影响需求管理、迭代规划、团队协作、测试、部署、监控、优化等所有项目管理环节对比维度传统软件项目AI Agent项目输出性质确定的、可预测的、可以用明确的功能点和测试用例来衡量的代码输入→固定逻辑→确定输出不确定的、概率性的、需要用业务指标和用户体验来衡量的智能体输入→LLM推理工具调用记忆规划反思→概率输出需求来源产品经理、客户、市场调研产品经理、客户、市场调研、Agent本身的表现不佳、LLM的更新换代、工具链的更新换代需求变更频率中等一般每个迭代1-3个P0/P1需求变更极高一般每个迭代3-10个P0/P1需求变更甚至每天都有临时需求变更核心开发任务编码、数据库设计、API设计、用户界面设计Prompt Engineering、工具集成、记忆设计、规划设计、反思设计、RAG框架优化、LLM Fine-Tuning、测试用例设计业务指标测试用例团队组成产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师、Prompt Engineer提示工程师、LLM Engineer大语言模型工程师、Data Scientist数据科学家、Agent Architect智能体架构师测试方式Unit Testing单元测试占比最高、Integration Testing集成测试、End-to-End Testing端到端测试、性能测试、安全测试Business Metric Testing业务指标测试占比最高、A/B TestingA/B测试、红队测试Red Team Testing专门测试Prompt Injection、越狱等安全问题、Human-in-the-Loop Testing人在回路测试、Unit Testing单元测试主要测试工具调用、记忆读写、数据格式转换等确定的逻辑迭代周期中等一般2-4周一个迭代Scrum框架常用2周Kanban框架常用1-2周极短一般1周一个迭代甚至1-3天一个“微迭代”验收标准明确的功能点验收、明确的测试用例通过率比如Unit Testing通过率≥95%Integration Testing通过率≥90%End-to-End Testing通过率≥85%明确的业务指标验收比如准确率≥0.85召回率≥0.8自然度≥4.0满分5.0用户满意度≥4.2满分5.0ROI≥1.2、明确的A/B测试结果验收、明确的红队测试通过率验收风险因素需求变更风险、技术债务风险、人员流动风险、成本超支风险、交付延期风险需求变更风险、技术债务风险、人员流动风险、成本超支风险、交付延期风险、LLM输出不确定性风险、Prompt Injection风险、数据隐私风险、LLM更新换代风险、工具链更新换代风险、多Agent协作混乱风险从上面的对比表格可以看出AI Agent项目的不确定性、复杂性、动态性都远远超过了传统软件项目——这就要求我们必须对传统的敏捷开发与迭代规划进行“定制化改造”才能应对这些挑战。1.3 亮明观点/文章目标 (The “What” “How”)1.3.1 文章目标读完这篇文章你将能够理解AI Agent Harness Engineering的核心概念和本质理解AI Agent项目与传统软件项目的9个本质区别掌握针对AI Agent项目定制化改造的Scrum框架——我称之为“Agent Scrum”框架掌握AI Agent项目的需求管理方法论——我称之为“Agent User StoryMVP最小可行产品MDP最小可行演示MUP最小可行产品上线”方法论掌握AI Agent项目的迭代规划方法论——我称之为“Business Metric-Driven Iteration Planning业务指标驱动的迭代规划Micro-Iteration微迭代Spike探索性任务”方法论掌握AI Agent项目的团队协作方法论——我称之为“Cross-Functional AI Agent Team跨职能AI Agent团队Daily Standup for AI AgentsAI Agent专用每日站会Sprint Review for AI AgentsAI Agent专用冲刺评审会Sprint Retrospective for AI AgentsAI Agent专用冲刺回顾会”方法论掌握AI Agent项目的风险评估方法论——我称之为“AI Agent Risk MatrixAI Agent风险矩阵”方法论掌握AI Agent项目的最佳实践和常见陷阱通过一个实战案例——“企业级AI文档审核Agent链”项目将上述所有方法论落地。1.3.2 文章内容预告接下来我将按照以下结构来撰写这篇文章基础知识/背景铺垫详细讲解Scrum框架的核心概念Product Backlog、Sprint Backlog、Daily Standup、Sprint Review、Sprint Retrospective、Product Owner、Scrum Master、Development Team以及为什么Scrum框架是最适合AI Agent项目的敏捷开发框架核心内容/实战演练Agent Scrum框架定制化改造详细讲解“Agent Scrum”框架的各个组成部分的定制化改造——包括Product Backlog的定制化改造Agent User Story的写法、MDP/MUP的定义、Sprint Backlog的定制化改造Business Metric-Driven任务划分、Spike的定义和使用、Micro-Iteration的定义和使用、Daily Standup的定制化改造AI Agent专用的三个问题、Sprint Review的定制化改造AI Agent专用的评审流程、Sprint Retrospective的定制化改造AI Agent专用的回顾流程、团队组成的定制化改造Cross-Functional AI Agent Team的定义和分工、风险评估的定制化改造AI Agent Risk Matrix的定义和使用核心内容/实战演练实战案例落地详细讲解“企业级AI文档审核Agent链”项目的需求分析、环境安装、系统功能设计、系统架构设计、系统接口设计、Agent Scrum框架的落地包括Product Backlog的编写、第一个Sprint的规划、第一个Daily Standup的召开、第一个Sprint Review的召开、第一个Sprint Retrospective的召开、风险评估的落地、系统核心实现源代码、测试结果、部署结果进阶探讨/最佳实践详细讲解AI Agent项目的常见陷阱与避坑指南、性能优化/成本考量、最佳实践总结行业发展与未来趋势详细讲解AI Agent项目管理的演变发展历史、未来发展趋势结论总结文章的核心要点、展望未来、发出行动号召。二、 基础知识/背景铺垫 (Foundational Concepts)2.1 Scrum框架的核心概念在讲“Agent Scrum”框架的定制化改造之前我们必须先回顾一下传统Scrum框架的核心概念——因为“Agent Scrum”框架是在传统Scrum框架的基础上进行定制化改造的。Scrum框架是由Ken Schwaber和Jeff Sutherland在1995年首次提出的它是一种迭代式、增量式的敏捷开发框架专门用于管理复杂的软件项目——现在已经成为全球最流行的敏捷开发框架根据VersionOne 2023年敏捷状态报告全球87%的敏捷团队使用Scrum框架或Scrum框架的变体比如Scrum of Scrums、Large-Scale ScrumLeSS、Nexus。传统Scrum框架的核心概念可以分为三个角色、三个事件、三个工件、五个价值观2.1.1 三个角色Three Roles传统Scrum框架有三个核心角色这三个角色必须是全职的、专注于当前项目的至少在Sprint期间是这样他们共同负责项目的成功1. Product Owner产品负责人Product Owner的核心职责管理Product Backlog负责收集、整理、排序、细化Product Backlog中的所有条目User Story、Bug、Technical Debt、Spike等确保Product Backlog中的条目是清晰的、可测试的、可交付的、有优先级的定义产品愿景负责向团队和利益相关者Stakeholder传达产品的愿景、目标、价值确保所有人都朝着同一个方向努力确定Sprint目标负责与团队一起确定每个Sprint的目标Sprint Goal并确保Sprint Backlog中的所有条目都是为了实现Sprint目标而存在的验收Sprint交付物负责在Sprint Review会上验收团队交付的增量Increment并决定是否将增量发布到生产环境与利益相关者沟通负责与客户、市场、销售、运营等利益相关者沟通了解他们的需求和反馈并及时调整Product Backlog的优先级。Product Owner的核心要求必须对产品有深刻的理解知道产品的价值是什么必须有决策权能够决定Product Backlog的优先级和Sprint的验收标准必须有良好的沟通能力能够与团队和利益相关者高效沟通必须有耐心能够接受需求的变更和团队的反馈。2. Scrum Master敏捷教练Scrum Master的核心职责引导团队遵循Scrum框架负责向团队和利益相关者培训Scrum框架的核心概念、价值观、事件、工件确保团队理解并遵循Scrum框架移除团队的障碍负责移除团队在开发过程中遇到的所有障碍——比如技术障碍比如服务器宕机、数据库连接失败、流程障碍比如审批流程太长、人员障碍比如团队成员之间的冲突促进团队的沟通与协作负责主持Daily Standup、Sprint Planning、Sprint Review、Sprint Retrospective等所有Scrum事件确保这些事件高效、有意义保护团队免受干扰负责保护团队在Sprint期间免受外界的干扰——比如利益相关者的临时需求变更、其他团队的请求除非这些干扰会直接影响Sprint目标的实现帮助团队持续改进负责在Sprint Retrospective会上引导团队反思过去一个Sprint的表现找出问题所在并制定改进计划帮助团队持续提升效率和质量。Scrum Master的核心要求必须对Scrum框架有深刻的理解是Scrum框架的“仆人式领导”Servant Leader——不是团队的老板而是团队的服务者必须有良好的沟通能力和冲突解决能力能够促进团队的沟通与协作必须有耐心能够接受团队的不足并帮助团队持续改进必须有一定的技术背景至少要了解团队的开发流程和技术栈能够帮助团队移除技术障碍。3. Development Team开发团队Development Team的核心职责交付增量负责在每个Sprint结束时交付一个“潜在可发布的增量”Potentially Shippable Increment——这个增量必须是完整的、可测试的、符合验收标准的自组织负责自己组织和管理工作——不需要Product Owner或Scrum Master来分配任务团队成员可以根据自己的技能和兴趣来认领任务跨职能必须具备完成Sprint目标所需的所有技能——不需要依赖团队外部的人员估算任务负责估算Product Backlog中的条目和Sprint Backlog中的任务的工作量参与所有Scrum事件负责参与Daily Standup、Sprint Planning、Sprint Review、Sprint Retrospective等所有Scrum事件。Development Team的核心要求必须是自组织的、跨职能的必须有良好的沟通能力和协作能力必须对自己的工作负责能够按时交付高质量的增量必须愿意学习新的技能和知识能够适应需求的变更和技术的发展。Development Team的规模传统Scrum框架建议Development Team的规模是3-9人——如果规模太小少于3人团队可能无法具备完成Sprint目标所需的所有技能如果规模太大多于9人团队的沟通与协作效率会大幅下降。2.1.2 三个事件Three Events传统Scrum框架有三个核心事件加上Sprint Planning就是四个事件不过很多资料把Sprint Planning也算作核心事件总共有四个Sprint Planning、Daily Standup、Sprint Review、Sprint Retrospective这些事件必须是时间盒的Timeboxed——也就是必须在规定的时间内完成不能拖延。时间盒是Scrum框架的一个核心原则——它可以帮助团队保持专注避免 scope creep范围蔓延提高效率。1. Sprint Planning冲刺规划会Sprint Planning的核心目的确定Sprint目标Sprint Goal确定Sprint Backlog中的条目——也就是团队在当前Sprint中要完成的任务估算Sprint Backlog中的任务的工作量分配Sprint Backlog中的任务给团队成员或者团队成员自己认领。Sprint Planning的时间盒传统Scrum框架建议Sprint Planning的时间盒是每个Sprint长度对应的8小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Planning的时间盒就是4小时如果Sprint长度是1周5个工作日那么Sprint Planning的时间盒就是2小时。Sprint Planning的流程传统Scrum框架的Sprint Planning分为两个部分第一部分WhatProduct Owner向团队介绍Product Backlog中优先级最高的条目团队和Product Owner一起讨论这些条目确定Sprint目标第二部分How团队讨论如何实现Sprint目标将Product Backlog中的条目分解成更小的、可执行的任务估算这些任务的工作量认领这些任务。2. Daily Standup每日站会Daily Standup的核心目的促进团队成员之间的沟通让团队成员了解其他人在做什么及时发现和移除团队遇到的障碍确保团队朝着Sprint目标前进。Daily Standup的时间盒传统Scrum框架建议Daily Standup的时间盒是15分钟——不管团队规模多大都必须在15分钟内完成不能拖延。Daily Standup的要求必须是“站会”——团队成员必须站着开会这样可以提高效率避免闲聊必须在同一时间、同一地点或者同一视频会议链接召开只有团队成员、Product Owner、Scrum Master可以参加——利益相关者可以旁听但不能发言除非团队邀请他们发言每个团队成员必须回答三个问题昨天我完成了什么What did I do yesterday that helped the Development Team meet the Sprint Goal?今天我打算完成什么What will I do today to help the Development Team meet the Sprint Goal?我遇到了什么障碍Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?3. Sprint Review冲刺评审会Sprint Review的核心目的向利益相关者展示团队在当前Sprint中交付的增量收集利益相关者的反馈根据利益相关者的反馈调整Product Backlog的优先级。Sprint Review的时间盒传统Scrum框架建议Sprint Review的时间盒是每个Sprint长度对应的4小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Review的时间盒就是2小时如果Sprint长度是1周5个工作日那么Sprint Review的时间盒就是1小时。Sprint Review的流程团队向利益相关者介绍Sprint目标的完成情况团队向利益相关者演示增量——注意是“演示”不是“讲解PPT”必须是真实的、可操作的增量利益相关者提问、反馈Product Owner、团队、利益相关者一起讨论反馈调整Product Backlog的优先级会议结束Scrum Master整理会议纪要。4. Sprint Retrospective冲刺回顾会Sprint Retrospective的核心目的反思过去一个Sprint的表现——包括团队的沟通、协作、效率、质量、流程、工具等找出问题所在制定改进计划帮助团队持续改进。Sprint Retrospective的时间盒传统Scrum框架建议Sprint Retrospective的时间盒是每个Sprint长度对应的3小时/月——比如如果Sprint长度是2周10个工作日那么Sprint Retrospective的时间盒就是1.5小时如果Sprint长度是1周5个工作日那么Sprint Retrospective的时间盒就是45分钟。Sprint Retrospective的流程传统Scrum框架的Sprint Retrospective有很多种流程——比如“Start-Stop-Continue”流程、“4LsLiked、Learned、Lacked、Longed For”流程、“Mad-Sad-Glad”流程我个人比较喜欢“Start-Stop-Continue”流程因为它简单、高效第一步Set the StageScrum Master向团队介绍回顾会的目的和流程确保团队成员放松、开放第二步Gather Data团队成员用便签纸写下过去一个Sprint中“我们应该开始做的事情Start”、“我们应该停止做的事情Stop”、“我们应该继续做的事情Continue”然后贴在白板上第三步Generate Insights团队成员一起讨论便签纸上的内容归类、合并相似的内容找出最重要的3-5个问题第四步Decide What to Do团队成员针对最重要的3-5个问题制定改进计划——改进计划必须是“具体的、可测量的、可实现的、相关的、有时限的SMART原则”第五步Close the RetrospectiveScrum Master总结回顾会的内容确认改进计划的负责人和截止日期整理会议纪要感谢团队成员的参与。2.1.3 三个工件Three Artifacts传统Scrum框架有三个核心工件这些工件必须是透明的、可见的、可访问的——所有团队成员和利益相关者都可以随时查看1. Product Backlog产品待办列表Product Backlog的定义Product Backlog是一个有序的、动态的列表包含了产品所需的所有功能、特性、需求变更、Bug修复、Technical Debt、Spike等条目——它是产品的“单一事实来源”Single Source of Truth。Product Backlog的特点有序的Product Owner负责对Product Backlog中的条目进行排序优先级最高的条目排在最前面动态的Product Backlog会随着产品的发展、需求的变更、利益相关者的反馈而不断更新——比如添加新的条目、删除旧的条目、调整条目的优先级、细化条目的内容透明的所有团队成员和利益相关者都可以随时查看Product Backlog可细化的优先级最高的条目会被细化成更小的、可测试的、可交付的条目——这个过程叫做“Product Backlog Refinement产品待办列表细化”。Product Backlog Refinement的时间盒传统Scrum框架建议Product Backlog Refinement的时间盒是团队总工时的10%左右——比如如果团队有5个开发人员每个开发人员每周工作40小时那么Product Backlog Refinement的时间盒就是每周20小时5×40×10%。2. Sprint Backlog冲刺待办列表Sprint Backlog的定义Sprint Backlog是一个由团队选择的、用于实现Sprint目标的Product Backlog条目列表加上团队为了实现这些条目而分解的更小的、可执行的任务列表——它是团队在当前Sprint中的“工作计划”。Sprint Backlog的特点由团队选择的只有团队可以选择Product Backlog中的条目加入Sprint Backlog——Product Owner可以建议但不能强制动态的Sprint Backlog会随着团队的开发进度而不断更新——比如添加新的任务、删除旧的任务、调整任务的优先级、标记任务的完成状态透明的所有团队成员和利益相关者都可以随时查看Sprint Backlog——通常会用“看板Kanban Board”来展示Sprint Backlog看板上有“待办To Do”、“进行中In Progress”、“已完成Done”三个列或者更多列比如“待测试To Test”、“测试中In Test”、“测试通过Test Passed”有时间限制的Sprint Backlog中的所有任务必须在当前Sprint结束前完成——除非团队和Product Owner一起决定修改Sprint目标。3. Increment增量Increment的定义Increment是团队在当前Sprint中交付的**“潜在可发布的产品增量”**——它必须是完整的、可测试的、符合“完成的定义Definition of DoneDoD”的。Definition of DoneDoD完成的定义的定义DoD是一个明确的、可测量的标准用于判断一个Product Backlog条目或任务是否“完成”——它是团队和Product Owner、利益相关者之间的“协议”。DoD的例子代码已经通过Code Review代码已经通过所有Unit Testing代码已经通过所有Integration Testing代码已经通过所有End-to-End Testing代码已经部署到测试环境代码已经通过Product Owner的验收文档已经更新没有严重的BugP0/P1 Bug。2.1.4 五个价值观Five Values传统Scrum框架有五个核心价值观这五个价值观是Scrum框架的“灵魂”——如果团队不遵循这五个价值观那么Scrum框架就只是一个“空壳”无法发挥作用Commitment承诺团队成员承诺完成Sprint目标对自己的工作负责Focus专注团队成员专注于Sprint目标专注于当前的任务不被外界的干扰所影响Openness开放团队成员开放地沟通开放地分享自己的想法、感受、问题、反馈Respect尊重团队成员尊重彼此的技能、经验、想法、感受Courage勇气团队成员有勇气说“不”——比如对不合理的需求变更说“不”对自己的错误说“不”有勇气尝试新的事物——比如新的技术、新的流程、新的工具。2.2 为什么Scrum框架是最适合AI Agent项目的敏捷开发框架现在市面上有很多敏捷开发框架——比如Scrum、Kanban、XPExtreme Programming极限编程、Lean精益软件开发、Crystal水晶方法论、DSDMDynamic Systems Development Method动态系统开发方法等等为什么我认为Scrum框架是最适合AI Agent项目的敏捷开发框架呢原因有以下五个2.2.1 Scrum框架的迭代式、增量式开发可以应对AI Agent项目的不确定性AI Agent项目的输出是“不确定的、概率性的”——比如我们无法100%确定Agent的准确率、召回率、自然度会达到多少无法100%确定Agent的工具调用是否会成功无法100%确定Agent的多Agent协作是否会混乱。而Scrum框架的迭代式、增量式开发可以帮助我们快速验证假设快速调整方向——比如我们可以在第一个Sprint中交付一个“单Agent简单工具调用”的MDP最小可行演示验证LLM的选择是否正确、工具调用的逻辑是否可行在第二个Sprint中交付一个“单AgentRAG框架”的MUP最小可行产品上线验证RAG框架的检索策略是否有效、准确率和召回率是否达到预期在第三个Sprint中交付一个“多Agent协作记忆规划反思”的增量验证多Agent协作的逻辑是否可行、自然度和用户满意度是否达到预期如果某个Sprint的验证结果不符合预期我们可以快速调整Product Backlog的优先级调整下一个Sprint的目标而不会像传统瀑布式开发那样等到整个项目完成后才发现问题造成巨大的损失。2.2.2 Scrum框架的时间盒可以应对AI Agent项目的范围蔓延AI Agent项目的需求变更频率极高——比如利益相关者可能会在看到MDP后提出很多新的需求比如“能不能让Agent支持Excel文档的审核”、“能不能让Agent支持多语言的审核”、“能不能让Agent支持语音输入”如果我们没有时间盒的限制就会陷入“范围蔓延”的陷阱——不断地添加新的需求不断地延期交付最终导致项目失败。而Scrum框架的时间盒可以帮助我们保持专注避免范围蔓延——比如我们可以在每个Sprint中只关注优先级最高的3-5个Product Backlog条目只关注Sprint目标利益相关者的新需求可以加入Product Backlog但只能在下一个Sprint或之后的Sprint中考虑除非这些新需求会直接影响当前Sprint目标的实现这种情况非常少见。2.2.3 Scrum框架的Product Backlog Refinement可以应对AI Agent项目的需求不明确AI Agent项目的需求通常是“不明确的、模糊的”——比如利益相关者可能会说“我想要一个‘智能的’文档审核Agent”但什么是“智能的”是准确率≥0.9是召回率≥0.85是自然度≥4.5是审核速度≤1秒/页利益相关者自己可能也不知道答案。而Scrum框架的Product Backlog Refinement可以帮助我们细化需求明确验收标准——比如Product Owner可以和团队、利益相关者一起通过“用户访谈”、“原型设计”、“MDP演示”等方式不断地细化需求明确验收标准尤其是业务指标验收标准把“不明确的、模糊的”需求变成“清晰的、可测试的、可交付的”Agent User Story。2.2.4 Scrum框架的Daily Standup可以应对AI Agent项目的团队协作复杂性AI Agent项目的团队组成比传统软件项目复杂得多——除了传统的产品经理、UI/UX设计师、前端开发工程师、后端开发工程师、测试工程师、DevOps工程师还有Prompt Engineer、LLM Engineer、Data Scientist、Agent Architect这些角色的工作内容和技能要求完全不同沟通与协作的难度很大。而Scrum框架的Daily Standup可以帮助我们促进团队成员之间的沟通及时发现和移除障碍确保团队朝着Sprint目标前进——比如Prompt Engineer可以在Daily Standup上告诉团队“我昨天优化了文档审核Agent的Prompt准确率从0.7提升到了0.8但召回率从0.85降到了0.75今天我打算调整Prompt的参数平衡准确率和召回率我遇到的障碍是不知道用什么指标来衡量‘平衡’”然后LLM Engineer或Data Scientist可以帮助Prompt Engineer解决这个障碍比如后端开发工程师可以在Daily Standup上告诉团队“我昨天完成了Milvus数据库的集成但连接不稳定经常超时今天我打算检查一下网络配置和Milvus的参数设置我遇到的障碍是没有权限访问云服务器的网络配置”然后Scrum Master可以帮助后端开发工程师移除这个障碍。2.2.5 Scrum框架的Sprint Retrospective可以应对AI Agent项目的持续改进需求AI Agent项目的技术发展非常快——比如LLM的更新换代从GPT-4到GPT-4o Mini到GPT-4o、Agent框架的更新换代从LangChain 0.1.x到LangChain 0.2.x、RAG框架的更新换代从简单的向量检索到混合检索到重排序到Multi-Query检索到RAG Fusion、工具链的更新换代从SerpAPI到Google Search API到Bing Search API如果我们不持续改进就会很快被淘汰。而Scrum框架的Sprint Retrospective可以帮助我们持续改进流程、工具、团队协作效率、产品质量——比如我们可以在Sprint Retrospective上讨论“我们是否应该把LangChain的版本从0.1.16升到0.2.0”、“我们是否应该用CrewAI来替代LangChain的Multi-Agent框架”、“我们是否应该用Milvus来替代Pinecone”、“我们是否应该把Daily Standup的时间从早上9点改到早上10点”、“我们是否应该增加Product Backlog Refinement的时间”然后制定改进计划帮助团队持续提升。三、 核心内容/实战演练Agent Scrum框架定制化改造 (The Core - “How-To”)在第二章中我们回顾了传统Scrum框架的核心概念以及为什么Scrum框架是最适合AI Agent项目的敏捷开发框架。在第三章中我们将针对AI Agent项目的不确定性、复杂性、动态性对传统Scrum框架进行定制化改造——也就是我今天要讲的Agent Scrum框架。Agent Scrum框架的核心思想是以业务指标为驱动以微迭代为补充以探索性任务为基础以跨职能AI Agent团队为核心以AI Agent专用的Scrum事件为流程以AI Agent专用的Scrum工件为产出以AI Agent风险矩阵为保障。接下来我将详细讲解Agent Scrum框架的各个组成部分的定制化改造3.1 三个角色的定制化改造Three Roles for AI Agents首先我们对传统Scrum框架的三个核心角色进行定制化改造——虽然这三个角色的核心职责和核心要求没有变但我们需要针对AI Agent项目的特点增加一些新的职责和要求3.1.1 Product Owner for AI AgentsAI Agent产品负责人除了传统Scrum框架中Product Owner的核心职责和核心要求AI Agent Product Owner还需要具备以下新的职责和要求新的职责定义业务指标Business Metrics负责与团队、利益相关者一起定义产品的核心业务指标North Star Metric北极星指标和辅助业务指标Secondary Metrics并确保这些指标是“SMART原则”的——具体的Specific、可测量的Measurable、可实现的Achievable、相关的Relevant、有时限的Time-bound管理业务指标的优先级负责对业务指标进行排序确保团队在每个Sprint中只关注优先级最高的1-2个核心业务指标参与Prompt Engineering和RAG框架优化的讨论虽然Product Owner不需要亲自写Prompt或优化RAG框架但他
