想象一下，作为一名软件开发者却无需编写任何代码。这听起来太美好了。事实上，在一些主流搜索引擎和音乐流媒体团队中，这就是现实：他们80%甚至更多的代码是由人工智能（AI）和这些新兴的AI编程助手编写的。这简直不可思议，但随着这种AI辅助开发实践的兴起以及所谓的“智能体工程”（agentic engineering）的出现，这已成为现实。但问题是：它是如何工作的？你应该了解什么呢？在接下来的几分钟里，我想解释构建和使用AI模型时你需要知道的五个最重要术语，并附带示例和最佳实践，以便你能像那些顶尖团队一样利用AI。所以，让我们从基础开始，逐步深入。
你可能听说过“提示工程”（prompt engineering）。这是指为模型制定正确指令的实践。那么，这类指令是什么样的呢？比如，“你是一名技术支持专家”，或者“仅基于提供的文档回答问题”。但你可能不知道的是，即使你拥有一个极其强大的大型语言模型（LLM）——我指的是那些最前沿、评分最高的模型，懂得如何沟通、能够清楚地向模型解释你想要什么以及希望它为你做什么，这比模型本身更重要。而这种沟通能力的需求，引出了“领域专业知识”（domain expertise）的重要性。无论是什么领域的专家都适用这一点。很多人认为，哦，我必须是一名开发者才能使用这些模型。其实不一定，但你确实需要在与模型协作完成的任务方面拥有经验。
有些人为了在提示工程期间进行有效沟通，会使用麦克风。他们可能会通过语音输入与其中一个LLM交谈几分钟。这效果非常好，因为这些高级模型确实能够准确捕捉你的意图。现在让我们谈谈较小的模型，即你可以本地运行或在边缘设备（甚至今天的手机）上运行的模型。对于这些较小模型的提示工程，我们通常看到的是提供“少样本”（few-shot）示例，即你希望模型复制的问题和答案。因此，你会提供这些被称为少样本提示的示例，连同你想要发送给模型的提示一起给出。比如，“嘿，我想让你解决这个问题”或“获取这位新用户的信息并给我们一个回复”，甚至提供所谓的“思维链”（chain of thought，简称COT）示例。当你从这些可以在笔记本电脑或智能手机上运行的小型LLM获取响应时，思维链能带来巨大的差异。
根据你打算使用的模型类型，你的指令可能会略有不同，但最终，朋友们，这一切都关乎沟通。但模型不仅仅看到你给它的指令，“上下文工程”（context engineering）就在这里发挥作用了。我想让你思考模型在其“上下文窗口”中看到的所有内容，对吧？这将包括系统提示（即告诉模型在这个用例中应该做什么），还可能包括加载的工具、MCP服务器和技能。它也可能包含PDF文件，或者你通过检索增强生成（RAG）拉取的信息来回答关于某个主题的问题。例如，对于编码智能体，你会看到你的代码库被添加到上下文窗口中。
即使你拥有一个拥有巨大上下文窗口的模型，质量在达到 advertised 限制之前就会下降。这就是为什么你会看到诸如将上下文窗口的内容压缩或总结为新提示的技术。例如，我们可以总结对话中发生的一些活动，将其浓缩为较小的一部分，然后作为新的提示交给模型。这些只是管理上下文窗口的方法。你还会经常看到使用子智能体（sub-agents）。子智能体允许我们执行研究、查看库或文档等操作，而不会显著增加原始上下文窗口的大小。当这些通常较小且目的明确的子智能体完成后，它们可以将信息添加回上下文窗口，从而在我们在工作中节省一些存储空间。这就是上下文工程的核心内容。
但即使拥有管理良好的上下文窗口，你可能注意到还缺少了什么，因为面对所有这些相关信息，这个极其强大的LLM将能够输出非常准确的答案。但我们怎么知道答案真的可行呢？朋友们，这就是“Harness工程”（harness engineering）的全部理念。Harness工程涵盖了让模型行动、验证其操作结果，并继续获取输出和输入的所有内容。它是实际执行命令的运行环境——比如你希望使用工具编辑文件，同时也管理上下文窗口。假设我们过载了原始的上下文窗口，如何继续拥有相同的记忆、提示和执行能力？同时，我们需要一个沙盒环境，因为我们不希望LLM能够对我们的计算机和机器做任何事情。Harness可以提供这些能力以及编排功能（orchestration）。
它可以协调我们之前提到的不同子智能体。Harness是一种让我们能够与自己机器交互的能力，同时也告诉模型：例如，当我们使用该工具时，在你推荐的更改之后测试套件是否通过了？或者说，比如我们现在尝试将代码添加回仓库时是否存在合并冲突？这种反馈让智能体能够自行迭代，而不需要你批准每一个步骤。目前大多数AI Harness已经与工具和服务连接在一起，比如你的CI流水线、可观测性堆栈以及你已有的所有组件。
你可能也听说过“循环”（loops）和“循环工程”（loop engineering），例如我能展示的最佳用例就是智能体循环本身。从一个初始目标开始，或者很多人直接使用提示，这允许智能体使用各种类型的工具进行操作并观察输出。在这一点上，它可以决定这是成功还是继续在循环中执行下去。朋友们，这本质上就是……
AI 智能体本质上是一个不断循环的过程。接着是“回路工程”的概念，即不再由人类像你我一样持续向智能体发出提示词，而是附加一个触发器。这可以是任何类型的触发器：例如每天早上 9 点（即定时任务），或有人在代码仓库中打开拉取请求，亦或是提交关于漏洞的问题报告或警报。回路工程意味着我们构建的是一个以预期目标为导向、为你编排智能体的系统。
通常，系统中会有“人在回路”来批准这些变更。因此，你可以在智能体开始行动并使用工具后进行检查，或者在观察其输出后进行审核。这样你就可以在这个工作流中检查正在发生的事情，并与智能体协作更高效、更高质量且更快地交付软件。
现在你有多个可以执行此工作的智能体，这就涉及“图工程”的概念。图工程是将同样的循环概念与多个并行连接智能体相结合。从预期目标、开始或触发点出发，我们可以拥有两个子代理：一个可能负责市场调研，另一个在研究代码仓库的结构。它们可以将工作移交给出实际上要实施开发的智能体。
因此，我们可以将这个循环概念分支扩展为各种图结构。但问题是，除非你有无限的令牌额度，否则你会发现这种实现方式成本颇高，因此你可能不会总是这样做。但这正是回路工程和图工程的概念。最后是所谓的“软件工厂”，这完全关于使用 AI 智能体自动化软件开发生命周期。
本质上，这是为传统的软件开发任务（如任务管理、代码实现或测试等）设置强大的流水线。与其使用一个试图处理所有事务的通用智能体，不如在软件工厂中使用基于单个任务的智能体。然而，这些组件都需要隔离性：使用容器或沙箱等进行隔离。
每个智能体还需要身份标识，即它们是谁以及能访问什么资源（例如通过 Git 或云环境）。此外，每个智能体在工作时还需要可观测性。如果它们昨晚凌晨 3 点还在工作，我们应该能够追踪工厂中某个智能体发生的所有事情。
许多团队开始构建这些 AI 软件工厂，随着模型变得更好，我认为这种情况只会越来越普遍。这里有五个术语，如果你作为工程师工作过，你会注意到这些并非全新的想法：图、反馈回路和分布式系统都是计算实践，但现在它们正在被重新发明。
不过关键在于：你不必精通所有这些知识。如果你只是独立开发者，就不需要软件工厂。但像提示词、上下文窗口和编排工程这样的概念适用于每个人。无论你是学生、设计师还是经理，都适用。请在评论中告诉我：这就是工程学的未来吗？或者什么对你有效？
一如既往，希望你在今天的视频中有所收获。请点赞以优化算法推荐。再见，我们下期见。