AI 模型
如果软件工程师不再亲自编写代码，他们该做什么？这是数百万人心中共同的疑问。
AI工具如今已被开发者广泛使用，但裁员的担忧依然挥之不去。另一方面，编写代码只是软件工程的一部分。这为工程师提供了一个机会——更贴近业务本身，更深入理解自身角色在组织和行业中存在的意义与背景。
"我喜欢用类比的方式思考。2009年，我问自己，如果运维能像开发一样会怎样？"Tessl技术人员、DevOps一词的创造者、全球DevOpsDays系列活动创始人Patrick Debois如此说道。
他在今年夏天于伦敦举行的PlatformCon大会上发表了上述观点，并告诉听众：随着"上下文"（即AI执行任务所依赖的特定知识）逐渐取代人工编写的代码，"软件开发生命周期正在演变为上下文开发生命周期"。
这一生命周期已从单一的CI/CD反馈循环，扩展为一系列同心循环，涵盖上下文的生成、基于测试驱动开发的评估、以包形式分发，以及对结果的观测。这种演进正是由个人开发者、团队乃至整个组织思维方式的转变所推动的，同时也为平台工程团队带来了全新的发展机遇。
"我想倡导开发者转变一种思维方式：当智能体没有按你的预期执行时，不要急着去改代码，而应该去改善整个系统，而不是调整提示词，"Debois对The New Stack表示，"这是从'我和我的智能体一起做'转变为'我帮我的智能体做得更好'。"
Debois认为，这是从确定性系统向非确定性、概率性系统和工作流转变的必然过程。这一转变涉及工作方式和技术本身的双重改变，而且不能仅靠个人工程师或单一团队来完成。就像DevOps一样，这种变革只有在规模化推进中才能真正实现。
从表面上看，似乎每家公司都在一夜之间宣称"AI优先"，但实际上，就像此前的DevOps、微服务和云转型一样，AI正在经历一场持续推进的长期演变。那么，工程组织该如何走上正确的上下文驱动之路？
在团队层面，Debois建议思考：智能体要正常运转，究竟需要经过多少次人工介入？不同团队的不同工程师会从各自角度输入不同的上下文内容，包括：
代码库
功能规格说明
故障复盘报告
文档与Slack消息
架构决策记录
代码示例
使用场景
合规指南
要让上下文和智能体真正实现规模化，就需要清楚地知道各个团队正在构建哪些智能体，以及这些智能体产出了什么。
"当你在为A优化，我们在为B优化时，就要确保我们提供的整体上下文是面向整个团队进行优化的，"Debois解释道，"如果你是在为自己的笔记本电脑优化这个系统，能否把它扩展为面向团队工作流的优化？然后再继续扩大，比如能否在平台层面实现，或者跨多个团队推广？"
"这不是你主动去寻找的东西，"Debois告诉The New Stack，"也许会有人加快这个进程，但你会看到这样的信号：'我有上下文，你也有上下文，现在都在Slack上，要不要把它放进代码仓库，让大家都能复用？'"这遵循的是技术领域的传播规律——任何趋势都是从一个爱好者，扩展到一个热情团队，再到多个团队，最终被纳入平台基础设施。
与所有工具驱动的变革一样，AI同样既关乎技术，也关乎人和流程。但他认为，工具本身会为行为方式的转变打开新的可能。
"根本性的变化在于系统，而不是提示词，"他继续说道，"然后寻找从个人到共享、再到团队协同构建上下文的协作路径。"
有些组织可能认为，上下文只需一次性输入到智能体系统中，或者在规则变更时每年更新几次就够了。但Debois警告说，这不是瀑布式开发，而是迭代的过程。如果上下文不持续迭代，工程师就会重蹈覆辙，不断调整提示词或直接修改代码。单纯依赖传统反馈循环，意味着你的AI智能体集群将难以实现投资回报。
"行业里有一种说法：AI出了问题，就用更多AI来解决，"Debois在PlatformCon的演讲中如此说道。他举例说明：一个大语言模型或AI智能体生成了一段代码，"我们让这个大语言模型来评估这段代码，它会像单元测试一样调用——但它并没有真正运行代码，只是看了看代码。"
这种做法有一定价值，比如用于验证API端点或执行其他二元质量门控，但他认为这远远不够。正确的做法是：在上下文中明确指定你的需求，由此驱动智能体如何运行和评估代码。
但这还不是终点。他认为，智能体AI成熟度的下一个阶段，建立在"执行框架"（Harness）和循环机制之上。
执行框架工程专注于构建围绕大语言模型的基础设施、护栏和工具，以支持可靠、自主的智能体的开发。
Debois将智能体的内部执行框架定义为：通过查询API暴露的日志、指标和追踪信息，"让编码智能体能够看到执行结果并持续改进"，这些信息共同构成了生成、评估、分发和观测的完整动态循环。
有了这种模式，智能体"能自主感知到出了问题，而无需你随时告知"，因为"它内置了传感器，知道什么失败了、什么得到了改善，然后可以回过头来持续改进这些边界"，即便工程师在进行硬编码操作时也是如此。
同样，执行框架不应孤立地服务于单个开发者或团队。
"他们构建的是面向所有人的执行框架，想象一下，当大家对测试方式、验证方式达成共识，把当前分散在各个团队的知识汇聚在一起，"Debois说，"人们开始在同一条流水线上构建。"
现实情况是，大多数组织最终会存在多条流水线，但这些循环将成为各组织反馈机制的新一轮演进。因此，为AI协调而构建，最终也将推动组织协作走向更高水平。
Q&A
Q1：Patrick Debois说的"上下文开发生命周期"是什么意思？
A：Patrick Debois认为，随着AI智能体逐渐替代人工编写代码，软件开发的核心工作正在从"写代码"转向"管理上下文"——即为AI提供任务所需的特定知识。这个生命周期涵盖上下文的生成、评估、分发和观测四个环节，形成类似CI/CD的持续迭代循环，而不再是传统的一次性交付。
Q2：智能体执行出错时，为什么不应该直接改代码或改提示词？
A：Debois指出，直接修改代码或反复调整提示词只是治标，真正的解决方案是改善整个系统，即优化智能体所依赖的上下文。如果上下文不够准确和完整，智能体就无法持续稳定地执行任务。从长远来看，应该通过完善上下文、构建执行框架和观测循环，让智能体能够自主感知问题并持续改进，而不是依赖工程师手动干预。
Q3：什么是智能体执行框架（Harness），它有什么作用？
A：执行框架是围绕大语言模型构建的基础设施和工具集，包括日志、指标和追踪信息，通过查询API对智能体暴露运行结果。它的作用是让智能体能够"看到"自己执行的后果，从而自主判断哪里出了问题、哪里有所改善，并不断优化自身行为，而无需工程师频繁介入。执行框架应面向整个团队甚至整个平台构建，而非服务于单个开发者。
