Transcript
00:00:00你可能已经听过无数次这样的说法：软件开发已经变了，
00:00:03但仅仅采用新工具只触及了表面，
00:00:06因为今天构建 System 的行为方式与旧软件完全不同。
00:00:10因此，企业赖以构建的框架也必须发生转变，
00:00:14因为如果你继续基于旧流程进行构建，就会遇到它根本无法解决的问题。
00:00:18所以，为了迎合这种不断变化的格局，
00:00:21开发者社区中涌现出了一个专门针对 Agent 打造的新框架。
00:00:25在视频结束前，我们将带你了解这个全新的生命周期框架，
00:00:29以及为什么你需要采用它。
00:00:31多年来，软件开发一直是在使用 SDLC。
00:00:35软件开发生命周期是过去几十年里一直使用的结构化流程，
00:00:39包含设计、开发、测试、部署、维护和持续支持等多个步骤。
00:00:45其核心思想是，软件开发应紧扣业务目标和用户需求，
00:00:51每个阶段的输出都会成为下一阶段的输入。
00:00:54但这套方法在 AI 进入技术领域之前才有效。
00:00:57自 AI 开始受到关注以来，它首先取代的就是编写代码。
00:01:02在 AI 出现之前，开发是一个需要重复编写大量代码的系统，
00:01:06通常是一个将来自各处的片段和逻辑合并在一起，以构建解决问题 System 的重复过程。
00:01:12随着模型变得越来越好，像 Claude Code 和 Cursor 这样的工具开始主导行业，
00:01:18单纯的 SDLC 已经失效了。
00:01:20它已经无法独自维系，必须做出改变才能提供真正的价值。
00:01:24这就是为什么要开发 Agenic 开发生命周期（即 ADLC）。
00:01:28它弥补了 SDLC 与当前技术领域之间的鸿沟。
00:01:32我们需要 ADLC，是因为在采用 SDLC 的 System 中，
00:01:36你在规划时就已经知道了 System 的行为，并且有办法对其进行验证。
00:01:41简单来说，SDLC 将软件视为静态的死物，而 ADLC 则将其视为活的系统。
00:01:47现在，由于 AI Agent 具有不可预测性，而且它们实际上是通过推理
00:01:53并让任务适应所处环境来不断演进的，因此很难用传统软件的指标来评估它们。
00:01:59开发 ADLC 的根本原因，就是 AI Agent 在生产环境中的非确定性。
00:02:05使用 AI Agent 时，存在着持续的学习和不断的开发，
00:02:09你无法预先确定 Agent 的输出会是什么样子。
00:02:12在使用 AI 时，你所做的决定取决于 Prompt、上下文、模型
00:02:16以及你连接的所有外部工具。
00:02:18模型本身仍然是不可预测的，所以我们无法百分之百准确地断定一个 Prompt 会返回什么。
00:02:25因此，你拥有的成功指标本质上与 SDLC 所使用的完全不同。
00:02:29ADLC 包含 7 个阶段，每个阶段都以某种方式映射到对应的 SDLC 阶段。
00:02:36无论你是否在开发 Agentic System，第一步永远是规划。
00:02:41改变的是你规划的方式。
00:02:43对于 Agent，你不能像非 Agentic System 那样进行规划，
00:02:46因为与传统系统不同，两者的逻辑流向完全无法同日而语。
00:02:51因此，ADLC 的第一阶段——准备与假设，
00:02:54旨在在致力于任何系统设计或模型之前，建立对问题的切实理解。
00:02:59涉及到 Agent 时，你需要理解用户将如何与系统交互，
00:03:04并与所有利益相关者协调，找出工作流在何处中断，
00:03:07以及重复的人工作业是什么样的，因为这正是 Agent 实际要解决的问题。
00:03:12然后，你审查现有的工作流和政策，看看目前是如何处理这些事情的，
00:03:16一旦明确了这一点，你就可以提出可测试的假设，确定 Agent 将在何处协助或自动执行该工作流。
00:03:22如果完全跳过这个阶段，我们最终可能会自动化错误的工作，
00:03:26结果不仅没有解决问题，反而可能让事情变得更糟。
00:03:28与 SDLC 相比，这里的区别在于行为。
00:03:31在 SDLC 中，行为是可以预测的，因为相同的输入总是会得到相同的输出。
00:03:37但由于模型的介入，ADLC 是概率性的，
00:03:40相同的输入可能永远不会导致完全相同的输出。
00:03:43有了这个认知，你需要做的第一步就是开启规划模式，
00:03:47让你正在使用的任何 Agent 去规划你正在开发的 Agent 的行为，而不是实现细节。
00:03:52提示它先不要考虑代码，而是勾勒出整个工作流，
00:03:56Agent 如何与用户交互、可能出现什么问题、可能存在什么开销，
00:04:00以及关于系统的所有其他假设。
00:04:03这样，你的 Agent 构建流程就会从核心假设开始，
00:04:06这会比直接跳进架构规划能提供更好的指导。
00:04:10在初始规划完成后，紧接着还有另一层，
00:04:13在这一层你需要正确地识别范围和问题。
00:04:16这实际上映射到了 SDLC 的分析阶段或可行性研究，
00:04:20在以前你习惯于在那时分析业务需求以及实现是否可行。
00:04:25所以 ADLC 的这个阶段映射为：识别重要流程及 AI 在解决这些流程中的角色，
00:04:31明确划定约束条件和技术边界，
00:04:33并预先定义清晰的业务和技术 KPI，例如时间、成本、延迟和可行性。
00:04:39你在此处还要定义权衡取舍，明确哪些因素是可以接受的，哪些是不可接受的。
00:04:44但这一阶段最核心的部分是正确映射人机协同的责任模型（Human-Agent Responsibility Model），
00:04:49因为这建立了一个问责结构。
00:04:52人类仍然需要对其进行审查，因为我们无法把所有决定都托付给 Agent。
00:04:56到本阶段结束时，你会拥有完善的文档，其中工作流步骤被明确定义并附有关键 KPI，
00:05:02人机责任模型也被清晰地呈现出来。
00:05:05这至关重要，因为一旦发生任何失败，你不能把责任全推给模型。
00:05:09责任最终仍然需要由人类来承担。
00:05:12这种人类责任规划在以前是不需要的，因为当时没有 AI 的参与。
00:05:17它定义了 Agent 的自主权边界，如果你跳过这一步，
00:05:21就是在拿你自己在生产环境中的合规性和问责制开玩笑。
00:05:24为了让 Agent 做到这一点，你再次使用规划模式，提示它去规划工作流、延迟、系统问题、
00:05:30架构中需要具备的所有功能，以及失败可能会是什么样子。
00:05:34一旦这些被清晰陈述，Agent 就会理解在构建时可以朝着哪个正确的范围进行迭代。
00:05:39定义好范围和高层功能后，就该进入设计阶段了。
00:05:43在这个阶段，我们要为 Agent 本身定义系统架构。
00:05:47在这里，你决定 Agent 将遵循什么模式，比如 ReAct 还是 Plan-and-Act，或者是多 Agent 架构，亦或你想要的任何方法。
00:05:54然后你规划数据从一个点到另一个点的流动，在有多个 Agent 参与时，这一点变得更加至关重要。
00:06:00Agent 应该获取正确的数据，否则它会制造麻烦而不是提供帮助。
00:06:05你还要规划成本结构，比如 Token 经济学、上下文编辑功能、压缩，
00:06:10并理解将此 Agent 部署到生产环境的成本会是什么样子，
00:06:14以及当它开始处理多个用户时会发生什么。
00:06:17现在，这也是你真正挑选想使用哪些模型、采用哪个编排框架、
00:06:23数据库以及涉及的所有其他技术的地方。也正是站在这里，你在写任何代码之前就定义好成功的目标，
00:06:28这样你就可以用 TDD（测试驱动开发）来构建 Agent。
00:06:32在系统上线之前，你已经考虑了延迟、准确性、幻觉以及类似问题中的权衡取舍。
00:06:38这个阶段同样需要你 Agent 的规划模式。
00:06:41你给它提示，让它勾勒出一个涵盖 Agent 架构、数据流、成本模型
00:06:46以及整体技术结构的全面设计，以便你带着具体的计划进入下一步。
00:06:51初始计划完成后，下一步就是模拟和价值证明（Proof of Value）。
00:06:55在这里，你使用真实世界的数据来测试你在早期阶段所做的假设。
00:06:59你创建原型，以便搞清楚是否值得进一步推进去构建这个 Agent。
00:07:04基本上，这是你决定是否应该开发该 Agent 的地方，因为在这个阶段失败的成本要低得多。
00:07:10因此，这里的心脏活动包括为行为测试准备数据集或基准事实（Ground Truth），
00:07:15构建原型以便你可以测试先前记录的高风险假设，
00:07:19并验证数据质量、幻觉率、准确性、响应质量和基准测试。
00:07:25你还会重新审视最初的假设，以确定它是否能提供投资回报。
00:07:30交付物是经过妥善衡量的性能和成本基准，
00:07:33以及前面提到的基准事实文档，它会作为回归测试和模型微调的测试资产。
00:07:40这个阶段充当了一个验证门禁。
00:07:42如果你的结果从这里顺利通关到下一阶段，你就可以继续开发这个 Agent。
00:07:46如果没有，那么这次构建就是失败的，而及早发现这一点要好得多，
00:07:50因为如果这东西进入了生产环境，造成的损害会严重得多。
00:07:54为了做到这一点，你提示你的 AI Agent 创建第一个原型，以便你可以根据刚刚完成的所有规划对其进行测试。
00:08:00但在我们继续之前，先听听我们的赞助商 Softr 怎么说。
00:08:04氛围编码（Vibe coding）工具在生成 UI 方面很棒，但当你需要真正的认证、
00:08:08用户角色、权限或真正能扩展的数据库的那一刻，一切都会分崩离析，你又得回去写代码。
00:08:14Softr 是一款 AI 应用构建器，只需一个提示词就能处理所有这些问题。
00:08:18你用简单的英语描述你的需求，AI 联合构建器就会一次性生成全栈、数据库、页面、导航、登录以及基于角色的权限。
00:08:28这些不是原型页面，它们是真正可用的。
00:08:30你可以预览应用，检查每个用户角色能看到什么，当你点击发布时，你的应用就上线了，托管、用户组、企业级安全和访问控制全都锁定就绪。
00:08:40而且你不需要开发人员来维护它。
00:08:42一切都是可视化的，所以你可以自己更新工作流、管理用户和添加功能。
00:08:47软件的真正成本不在于构建，而在于维护，这正是 Softr 所解决的问题。
00:08:52点击描述中的链接获取免费的 AI 额度，立即开始吧。
00:08:57这标志着规划阶段的结束，它带我们来到了许多人直接跳进去的部分，那就是实现。
00:09:03前面的步骤真的很重要，因为如果你正确地完成了它们，你就不会遇到大多数人因为跳过这些阶段而在这里碰到的问题。
00:09:11所以，这才是你真正开发 Agent、构建核心逻辑并编排开发工作流的时候。
00:09:16在这里，你会看到 SDLC 和 ADLC 之间最清晰的分水岭之一。
00:09:20在 SDLC 中，逻辑存在于代码、配置和第三方依赖项中。
00:09:25在 ADLC 中，该逻辑分布在代码、Prompt、模型、工具和外部服务中。
00:09:30所以你不再只是管理软件，你是在共同管理所有这些层，其中任何一层都可以改变系统的行为方式。
00:09:38如果你有多个 Agent 系统需要开发，编排工作流的一种方式是 Claude Code 中全新的 Agent 视图。
00:09:44使用 Agent 视图，你可以比常规使用 Claude 更好地委派任务。
00:09:49因为你不需要管理不同的 Claude Code 会话，而是管理一个单一的编排层，并给予 Agent 管理器提示词来通过它协调所有 Agent。
00:09:57现在在这个时间点，你会集成像 MCP 和 API 这样的工具。
00:10:01例如，如果你正在构建一个个人助手，你知道它会需要像 Google Calendar MCP、Gmail MCP，可能还有 Notion MCP 这样的东西。
00:10:09而这里最重要的事情是上下文管理（Context Management）。
00:10:11因为一旦你为生产环境构建了一个 Agent，它就会成为最关键的方面之一。
00:10:16即使是目前可用的最大上下文窗口，比如 Gemini 和 Opus 中 100 万个 Token 的窗口，也仍然需要精心处理。
00:10:24你必须确保 Agent 留存了正确的记忆，并避免上下文腐化（Context Rot）。
00:10:28因为如果它最终充斥了太多无关信息，它的注意力就会分散到各处，输出也会变差。
00:10:34在这个阶段，你还需要从开发人员的角度进行测试，通过对照需求手动验证 Agent 设置，确保每次更改后行为的一致性。
00:10:44在 Agent 系统中，开发和验证并不是分离的。
00:10:48没有不断的测试你就无法前进，因为即使是一个微小的改变也会对整个工作流产生巨大的影响。
00:10:54因此，你需要在构建 Agent 的同时进行开发人员级别的验证，而不是仅仅依赖稍后单独的测试步骤。
00:11:01当你完成了系统的构建，测试就成了下一个阶段。
00:11:05如前所述，测试需要在构建过程中持续进行，但一旦你的系统构建完成，你就要在类似生产的环境下测试它，而不是将其作为单独的组件。
00:11:14这是你执行集成测试的阶段。
00:11:16你还要进行用户验收测试，从系统的实际用户那里收集反馈，并将其重新融入到系统中。
00:11:24你在偏见、合规性、性能和其他风险相关维度等多项因素上进行测试，以确保版本在上线前是安全的。
00:11:32而这也是成功指标完全转变的地方。
00:11:35在 SDLC 中，你通过简单地通过或失败的测试来衡量功能正确性。
00:11:40在 ADLC 中，你衡量的是准确率分布、幻觉率和单次结果成本，因为这些都无法干净地归结为单一的通过或失败。
00:11:48测试范式本身也随之发生移动。
00:11:50在 SDLC 中，预定义的测试验证了已知的代码路径。
00:11:54在 ADLC 中，那变成了对推理、安全性和工具使用的持续评估，因为 Agent 不会以相同的方式运行两次相同的路径。
00:12:02有像 RAGAS 和 DEEPVAL 这样的多个评估框架，但验证正确性的主要依据是你的数据在你之前定义的指标上的表现如何。
00:12:12而且有几种测试 Agent 系统的方法，包括功能测试、非功能测试、结构测试和压力测试。
00:12:18其中的每一项都必须彻底执行，通常使用的是 Agent 系统本身，这样才能正确地识别出边缘情况并在它们到达生产环境前予以修复。
00:12:27另外，如果你喜欢我们的内容，请考虑按下点赞（hype）按钮，因为这能帮我们创作更多像这样的内容并触及更多的人。
00:12:34一旦你的系统准备就绪，就到了部署它并让它面向现实世界的时候了。
00:12:39你不能直接部署完就了事，因为对于 Agent 系统来说，这其中涉及的东西要多得多。
00:12:44对于普通系统，部署通常意味着将其推向生产环境并监控系统健康状况。
00:12:49对于 Agent 系统，情况完全不同，在这里，部署本身的含义发生了变化。
00:12:54在 SDLC 中，部署是开发的终点和一个稳定运行阶段的起点，也就是软件进入其平稳期的节点。
00:13:02在 ADLC 中，部署是主动监控和控制的开始，受到模型更新、上下文漂移和环境变化的塑造，这些在你交接后仍会继续发生变动。
00:13:11所以，即使开发可能已经完成，这个阶段甚至更加关键，因为你现在必须主动监控行为指标和系统指标。
00:13:19你还需要时刻关注质量、安全和性能问题的告警规则，以便在大规模生产错误发生前及早捕捉到它们。
00:13:28部署本质上是在真实用户与系统交互时，带有持续观察的受控激活。
00:13:34你不用只专注于系统健康，而是专注于行为表现，这样问题就能在波及所有用户之前被及早发现。
00:13:41在实践中，你先将系统发布给有限的一组用户，让他们在真实条件下使用。
00:13:46然后你观察该 Agent 系统随着时间的推移是如何响应的，然后再逐步推广给所有人。
00:13:52在实现经历了所有流程之后，它变成了一个维护、持续学习和增长的循环往复的周期。
00:13:58这是一个重要的阶段，因为它能让 Agent 保持准确并与现实世界的需求对齐。
00:14:03对于传统系统，反馈回路相对简单。
00:14:06用户报告一个 Bug，开发人员对其进行迭代并修复它。
00:14:10对于 Agent 系统，情况相当不同，因为它们基于一个在任何节点都不会停止的持续改进流程。
00:14:16这个周期不断精炼模型，所有负面信号都会被反馈回去，以便它能随着时间的推移改进其行为。
00:14:22这通常是通过 UI 信号（如点赞和踩）来完成的，以捕捉用户在看到响应后的感受。
00:14:29许多生产系统已经使用了类似的机制，比如在多个输出之间进行选择或对响应进行排序，就像在 ChatGPT 或 Claude 的反馈系统中所看到的那样。
00:14:39然后这些信号会被喂回给 Agent 系统，以便它可以学习并朝着更好的表现进行迭代。
00:14:44还有对数据源和 Embedding 进行定期更新，以确保系统保持最新状态，不会因过时信息而受损。
00:14:52必须不断监控对齐情况，以便安全性和护栏针对所有类型的提示词（包括提示词注入等风险）保持有效。
00:15:00这里的关键变量是持续的成本管理、质量跟踪、产品改进待办列表和模型升级，所有这些都需要持续维护，以使系统在长期内保持稳定、安全和正常运转。
00:15:11这带我们来到了本视频的尾声。
00:15:13如果你想支持本频道并帮我们继续制作像这样的视频，可以通过下面的超级感谢（super thanks）按钮来实现。
00:15:20一如既往，感谢你的观看，我们下期视频再见。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video