AI智能体开发实战：从提示工程转向上下文工程的完整指南

还记得去年各大公司给提示工程师开出30万美元年薪的疯狂时期吗现在这些招聘信息基本销声匿迹了。从技术角度看提示工程确实有些投机取巧的意味——本质上就是让人们相信自己在做工程工作的华丽包装。不过现在情况完全不同了。人们开始把传统软件工程的严谨方法和大语言模型的能力结合起来。这篇文章会深入探讨如何构建真正可扩展、生产环境稳定的智能体工作流。上下文工程才是核心虽然我从一开始就对提示工程持保留态度但不得不承认这个领域的确积累了不少有价值的经验。没有万能的提示技巧但针对特定数据集和场景某些提示方法确实能带来明显的性能提升。既然特定的提示技巧能让语言模型表现更好我们当然应该了解这个技术图谱合理运用各种提示方法。关键在于单纯的提示远远不够——它只是上下文工程的一个小组成部分。软件开发最初采用有向图结构类似流程图的形式来表示顺序或分支逻辑。后来出现了Apache Airflow、Prefect、Dagster这些工具将工作流正式化为DAG支持监控、重试、模块化和可观测性。随着机器学习的发展ML模型变得实用起来DAG开始嵌入模型处理步骤比如分类、摘要但整体还是确定性的——LLM只是静态流水线中的一个环节。智能体的出现改变了这种静态DAG的局限。你不需要编码每一个步骤而是定义目标和允许的状态转换让LLM来动态规划执行路径。这意味着代码量更少错误恢复能力更强智能体的行为也更具创造性和适应性。微智能体模式的工作原理很直接LLM生成JSON格式的工具调用下一步动作确定性代码执行这个调用将结果追加到上下文中然后重复这个过程直到任务完成。这种方式用灵活的迭代工作流取代了固定的DAG执行。上下文增长会导致智能体漂移出现重复动作或失去连贯性的问题。长上下文窗口10-20轮对话会严重降低可靠性即使是高质量的LLM在这种情况下也会表现不佳。许多研究表明LLM在超过32k上下文窗口后可靠性显著下降即便它们能处理百万级token。上下文越长产生幻觉的概率就越高。自然语言到工具调用的转换软件本质上就是控制信息流使用自由形式的LLM大多数情况下帮助不大。我们真正需要的是结构化、可控的输出。结构化输出通过将意图绑定到明确定义的操作来防止歧义和执行错误同时支持确定性程序执行让智能体行为变得可预测和可追踪。每个智能体动作都应该对应一个离散、定义明确的工具调用比如summarize_email、deploy_service。要避免多步骤或模糊的指令力求每次调用都是单一意图的转换。如果模型对意图不确定置信度低于阈值应该升级到人工干预而不是冒险执行错误的操作。用户输入Show me tomorrows meetings.智能体输出{ action: get_calendar_events, date: 2025‑08‑05 }掌控提示内容始终完全控制你的提示内容——把提示当作一等公民的软件工件而不是不透明的抽象层或框架管理的黑盒。提示即函数的模式示例function determineNextStep(thread: string): NextStep { prompt You are a helpful assistant that manages deployments. Conversation: ${thread} What should the next step be? }掌控提示的核心优势包括完全控制意味着你能精确编写智能体需要的指令不存在黑盒抽象测试和评估方面你可以像测试其他代码一样测试和评估提示快速迭代基于实际表现修改提示透明性清楚知道智能体在使用什么指令角色黑客技巧利用支持非标准user/assistant角色用法的API比如已弃用的非聊天版OpenAI completions API包括一些model gaslighting技术。注意提示是应用逻辑和LLM之间的主要接口。完全控制提示为生产级智能体提供了必需的灵活性和可控性。我不知道什么是最佳提示但我知道你需要能够尝试所有方法的灵活性。上下文窗口的精准管理控制对软件来说就是一切。Karpathy的建议永远值得听。要有意识地设计上下文而不是被动地通过聊天日志或一刀切的消息格式来填充。为什么这很关键信息效率XML/YAML等结构化格式能用更少的token表达更多含义最大化稀缺的上下文容量。错误恢复在上下文中记录工具输出和错误状态让模型能够推理出错的原因并智能重试。隐私和安全主动排除无关或敏感数据降低风险并满足合规要求。格式灵活性随着系统演进调整schema在运行时重构或裁剪条目。与工具和记忆的集成上下文可以嵌入RAG检索的文档、过去的工具调用和记忆摘要支持更丰富的推理。掌控上下文窗口的关键好处信息密度最大化LLM的理解错误处理以帮助LLM恢复的格式包含错误信息考虑在错误解决后从上下文中隐藏它们安全性控制传递给LLM的信息过滤敏感数据灵活性随着用例学习调整格式Token效率为token效率和LLM理解优化上下文格式。工具作为结构化输出不要把工具调用当作黑盒API代理而应该视为显式的、结构化的决策文档——通常是JSON格式——包含明确定义的字段。这些输出是LLM推理和实际执行动作的确定性软件之间的接口。定义一个显式schema比如通过JSON Schema或类型化数据类来强制包含关键字段如action_type、target、可选元数据和confidence_score。例如{ action: deploy_service, service: backend, version: v1.2.3, requires_approval: true, confidence: 0.92 }关于纯文本提示 vs 工具调用 vs JSON模式的优劣以及各自的性能权衡已经有很多讨论了这里就不细说了统一执行状态和业务状态即使在非AI领域许多基础设施系统也试图分离执行状态和业务状态。对于AI应用这可能涉及复杂的抽象来跟踪当前步骤、下一步、等待状态、重试次数等。这种分离会带来复杂性有时是值得的但对你的用例可能是过度设计。选择权在你手里。但不要认为你必须分别管理它们。执行状态包括当前步骤、下一步、等待状态、重试次数等业务状态是智能体工作流到目前为止发生的事情比如OpenAI消息列表、工具调用和结果列表等。如果可能的话简化——尽最大可能统一这些状态。这种方法有几个好处简单性——所有状态的单一真实来源序列化——线程可以轻松序列化/反序列化调试——整个历史在一个地方可见灵活性——通过添加新事件类型就能轻松添加新状态恢复——通过加载线程就能从任何点恢复分叉——通过将线程的某个子集复制到新的上下文/状态ID可以在任何点分叉线程人类界面和可观测性——轻松将线程转换为人类可读的markdown或丰富的Web应用UI。用户、应用、流水线和其他智能体应该能够通过简单的API启动智能体。智能体及其编排的确定性代码应该能在需要长时间运行的操作时暂停智能体。webhook等外部触发器应该能让智能体从中断的地方恢复而不需要与智能体编排器深度集成。生命周期管理启动、暂停、恢复默认情况下LLM API依赖一个根本性的高风险token选择我们是返回纯文本内容还是返回结构化数据好处清晰指令——不同类型人类交互的工具让LLM能给出更具体的指令内环vs外环——支持传统ChatGPT风格界面之外的智能体工作流控制流和上下文初始化可能是Agent-Human而不是Human-Agent想想由cron或事件触发的智能体多人类访问——通过结构化事件轻松跟踪和协调不同人类的输入多智能体——简单抽象可以轻松扩展以支持Agent-Agent请求和响应持久性——结合上述因素这使得持久、可靠、可检查的多人工作流成为可能。