停止修正AI代码：构建智能体所需的系统

如果软件工程师不再编写代码，那他们在做什么？这是数百万人心中的疑问。AI工具如今已被开发者广泛使用，但裁员恐惧依然存在。然而，编码只是软件工程的一部分。这为工程师提供了贴近业务和了解其角色在组织与行业中的目的的机会。Tessl的技术人员、DevOps一词的创造者、DevOpsDays全球活动系列的创始人Patrick Debois表示：“我喜欢用类比思考。2009年，我在想，如果运维更像开发会怎样？”他在今年夏天的伦敦PlatformCon会议上发表了上述言论。他告诉听众，随着上下文——AI用于任务的特定知识——取代人类代码，“软件开发生命周期变成了上下文开发生命周期。”这一生命周期已从单一的CI/CD反馈循环扩展为围绕生成、通过测试驱动开发评估、将上下文作为包分发以及观察的一系列同心圆。这种增长由个人开发者、团队和整个组织思维方式的转变所推动，并为平台工程团队开辟了全新的机遇。Debois告诉The New Stack：“我主张的开发人员思维转变是：如果智能体没有按你的意愿行事，停止修正代码。改进系统，而不是提示。这种转变是从‘我将与智能体一起做’转向‘我将帮助智能体做得更好’。”Debois认为这是从确定性到非确定性和概率性系统及工作流程的必要转变。它涉及工作方式和技术本身的诸多变化，但不能仅由单个工程师或团队层面完成。就像DevOps一样，这种变化只能在规模上实现。

如何成为上下文驱动的组织？可能感觉我们好像按下了开关，每家公司都“AI优先”。实际上，就像之前的DevOps、微服务和云转型一样，AI正在向可预见的未来持续过渡。那么，你的工程组织如何走上正确的上下文驱动之路？在团队层面，Debois表示，一个好的问题是：智能体工作需要多少次接触？不同团队的工程师会输入不同的上下文点，包括代码库、规范、事后分析、文档、Slack消息、架构决策记录、代码示例、用例和合规指南。要使上下文以及智能体规模化，你需要了解个人和团队正在生产哪些智能体及其输出。Debois解释说：“当你在优化A，我们在优化B时，我们要确保提供的整个上下文是针对整个团队优化的。”包括：“如果你在为你的笔记本电脑优化系统，我们能否为团队工作流程优化它？然后你只需扩展，比如，我们能否在平台层面做到这一点？或者跨多个团队？”Debois告诉The New Stack：“这不是你刻意追求的东西。也许他们可以加速它，但你会看到这样的迹象：‘哦，我有上下文，你也有上下文。当然，它就在Slack上。如果它放在仓库里，我可以重复使用呢？’这遵循了技术中任何趋势从单个爱好者扩展到热情团队、再到几个团队，最终构建到平台中的模式。像所有工具驱动的变革一样，AI既关乎人和流程，也关乎技术。但他认为，工具为行为改变打开了可能性。他继续说：“根本性的变化是系统，而不是提示。然后寻找协作方向，从单打独斗到共享事物，现在作为团队一起构建上下文。”

上下文工程演变为配套工程。组织可能认为上下文只需一次性或每年几次在规则变更时输入智能体系统，但Debois警告说，这不应是瀑布式。它是迭代的。如果上下文不是迭代的，那么工程师就会重新陷入改写提示或直接修复代码本身的坏习惯。仅依赖传统反馈循环意味着你的AI智能体舰队无法带来投资回报。Debois告诉PlatformCon听众：“行业内有一种说法：如果AI有问题，我们就使用更多AI。”他举例说明一个大语言模型或AI代理如何生成代码。“我们要求LLM评估这段代码，它几乎就像调用单元测试一样。它没有运行代码，只是查看代码。”这有一定价值，可能在于强制API端点或其他二进制质量门控，但他说这还不够。相反，如果你在上下文中指定了需求，那么这就会驱动智能体如何运行和评估代码。但不应止步于此。他认为，AI智能体成熟度的下一阶段在于配套和循环。配套工程专注于构建围绕LLM的基础设施、护栏和工具，以支持可靠、自主的智能体开发。Debois将智能体的内部配套定义为查询API背后的日志、指标和跟踪，“这样编码智能体就能看到后果并改进”，所有这些都反馈到生成、评估、分发和观察的活循环中。通过这种模式，智能体“自动知道出了问题，无需你不断告诉它们”，他说，因为“它拥有传感器，知道什么失败了，什么改进了，然后可以回去改进这些边界”，即使工程师在硬编码某些东西。同样，配套不应孤立地为单个开发者或团队构建。Debois说：“他们正在为整个世界构建配套，所以想象一下，在如何做测试、如何进行验证以及当前所有不同团队的知识方面达成共识。人们开始基于相同的管道进行构建。”现实是大多数组织最终会有多个管道，但这些循环成为每个组织反馈循环的下一步演进。因此，为AI协调而构建会带来更好的组织协作。