从代码工程到Agent工程：非确定性AI时代的软件范式变革-平芜编程栈

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

你有没有过这样的体验：花了整整一周，把一个复杂的业务逻辑用代码写得清清楚楚，单元测试全部通过，部署上线，然后……用户一个你完全没预料到的操作，系统就崩了。你打开日志，发现不是你的代码逻辑错了，而是用户输入了一个你从未考虑过的、极其“自然”但“不合规”的请求。在传统的软件世界里，我们总在试图用代码穷举所有可能性，用if-else筑起高墙。但墙再高，也总有翻不过去的“意外”。

现在，想象另一种可能：你不再需要为每一个“意外”写死代码。你构建的系统，核心不再是一行行冰冷的指令，而是一个能理解意图、会调用工具、能自我修正的“数字员工”。它面对未知时，不是报错，而是尝试、规划、执行，甚至向你请教。这听起来像科幻？不，这正在成为现实，而它的名字叫Agent（智能体）。

最近，LangChain 创始人 Harrison Chase 在一次对话中抛出了一个判断：2026 年将成为“Agent 工程”的分水岭，传统软件公司的生存考验开始了。这个判断的核心，不在于 AI 模型又变强了多少，而在于一种根本性的工程范式正在发生转移。过去几十年，软件工程有一个稳定不变的前提：系统的行为写在代码里。工程师读代码，就能推断系统在大多数场景下会怎么运行。但 Agent 的出现正在动摇这个前提：在 Agent 应用里，决定行为的不再只是代码，还有模型本身——一个在代码之外运行、带着非确定性的黑箱。

这意味着什么？意味着我们过去赖以生存的“确定性”开发、测试、调试方法，在 Agent 时代可能部分失效。你无法只靠读代码理解它，只能让它跑起来、看它在真实输入下做了什么，才知道系统“到底在干什么”。这不仅是技术的升级，更是对软件公司组织能力、工程思维和产品形态的一次彻底拷问。本文将带你深入这场变革的核心，拆解从“代码工程”到“Agent 工程”的跃迁，并探讨我们每个人该如何应对。

1. 从“确定性代码”到“非确定性黑箱”：工程范式的根本转移

要理解 Agent 工程带来的冲击，首先要看清传统软件工程与 Agent 工程最底层的区别。这个区别，Harrison Chase 用一句话点破：“真相的来源（source of truth）变了。”

1.1 传统软件：逻辑即代码，调试靠断点

在传统软件开发中，我们信奉的是“逻辑即代码”。一个函数接收什么参数，经过哪些条件判断，最终返回什么结果，都白纸黑字地写在.py、.js或.java文件里。当系统出现异常时，我们的排查路径是清晰且线性的：

复现问题：找到能稳定触发 Bug 的输入。
定位代码：通过日志、堆栈信息定位到出错的函数或模块。
分析逻辑：阅读相关代码，理解当前的执行路径和状态。
修改与验证：修改代码逻辑，增加边界条件，然后重新运行测试。

整个过程中，代码是唯一的“真相”。我们通过阅读代码来理解系统，通过修改代码来改变系统行为。调试工具（如断点、单步执行）的本质，是让我们能更清晰地“看到”代码执行过程中的状态变化。这是一种高度确定性的、可推理的工程模式。

1.2 Agent 应用：逻辑 = 代码 + 模型，调试靠“轨迹”

Agent 应用则完全不同。它的核心是一个大语言模型（LLM），这个模型本身是一个拥有数百亿甚至数千亿参数的“黑箱”。你无法通过阅读这些参数来理解它面对特定输入时会输出什么。在 Agent 系统中，决定最终行为的，是以下三者的复杂交互：

你的代码（框架/Harness）：定义了工具（Tools）、记忆（Memory）、规划（Planning）等组件的交互流程。
模型（LLM）：根据当前上下文（Context），非确定性地决定下一步行动（如调用哪个工具、输入什么参数）。
外部环境与历史：工具执行的结果、之前的对话历史（记忆）会不断被加入上下文，影响模型后续的决策。

在这种情况下，你无法仅通过阅读“框架代码”来预测 Agent 在真实场景下的完整行为。代码只定义了“舞台”和“道具”，而“演员”（模型）会如何即兴发挥，你必须在它“演出”（运行）时才能知道。

因此，Agent 时代的“真相来源”，从单一的代码，变成了“代码 + 执行轨迹（Trace）”。这里的 Trace 不是传统意义上记录错误信息的日志，而是 Agent 在完成一个长任务过程中，每一步的完整快照：它当时“想”了什么（模型的内部推理），它决定“做”什么（调用的工具和参数），以及“做”的结果是什么。

注意：这正是 LangChain 的 LangSmith 等工具变得至关重要的原因。它们提供的 Trace 功能，让开发者能够像看一场电影的逐帧回放一样，审视 Agent 的完整决策过程。当用户报告“Agent 跑偏了”时，开发者的第一反应不再是“把代码发给我看看”，而是“把 LangSmith Trace 链接发给我”。

1.3 新范式的核心挑战：测试与评估的变革

范式的转移直接冲击了软件工程中最基础的环节：测试。

传统测试：基于确定性的输入输出。我们编写单元测试（给定输入 A，断言输出为 B）和集成测试。只要代码逻辑不变，测试结果就是稳定的。
Agent 测试：输入输出关系是非确定性的。同样的提示词（Prompt），模型可能给出不同的回答；同样的任务，因为外部API返回结果稍有不同，Agent 可能选择完全不同的执行路径。

那么，如何测试一个 Agent？Harrison Chase 指出了两个关键方向：

在线测试（Online Testing）与人类评判：由于 Agent 的行为需要在真实世界的输入驱动下才会“涌现”，因此在线测试变得比离线测试更重要。同时，评估 Agent 的输出往往需要人类的判断（例如，这份研究报告质量如何？这个代码修改是否正确？）。因此，将人类反馈（Human-in-the-loop）引入开发流程，通过标注 Trace、给出自然语言反馈或直接纠正，成为了构建可靠 Agent 的核心环节。
LLM-as-a-Judge（模型作为评判官）：完全依赖人力成本过高，于是出现了用另一个 LLM 来评估 Agent 输出的方法。但这并非易事，关键在于校准（Calibration）：你必须确保这个“法官模型”的判断与真实人类的偏好保持一致。这催生了“对齐评估（Align Evals）”等新实践——先由人类标注一批 Trace，然后用这些数据去校准一个 LLM Judge。

小结：Agent 工程不是给传统软件“加一层AI壳”，而是从“编写确定性逻辑”转向“引导和评估非确定性行为”。工程师的核心技能，从“写完美的代码”部分转向了“设计高效的交互流程”、“构建可靠的评估体系”和“解读复杂的执行轨迹”。

2. “上下文工程”与“Harness”：Agent 时代的新基础设施

如果说模型是 Agent 的“大脑”，那么让这个大脑能稳定、高效工作的“身体”和“工具”，就是Harness（运行框架）和Context Engineering（上下文工程）。这是 Agent 从概念走向实用，尤其是支撑“长任务 Agent（Long Horizon Agents）”的关键。

2.1 为什么是“Harness”，而不仅仅是“Framework”？

早期，LangChain 被描述为一个 Agent Framework（框架）。Framework 更偏向于提供灵活、通用的基础设施组件（如工具调用、记忆存储），让开发者可以自由组装。而Harness 则是一个“有主张”的运行时环境。它内置了一系列默认的最佳实践和设计选择，让开发者能更快地构建出可用的 Agent。

以 LangChain 的 Deep Agents 为例，作为一个 Harness，它默认就提供了：

规划工具（Planning Tool）：内建了让 Agent 进行任务分解和规划的能力。
上下文压缩（Compaction）：当任务运行时间很长，上下文窗口（模型能“记住”的对话历史长度）不够用时，Harness 会自动决定如何压缩或总结历史信息，将关键内容保留，细节存入外部存储（如文件系统）。
文件系统交互：几乎成为长任务 Agent 的标配。文件系统不仅是存储工具，更是上下文管理的核心组件。

Harrison Chase 强调，文件系统的访问能力对于长任务 Agent 至关重要。它解决了两个核心问题：

状态持久化：Agent 可以将中间结果、完整日志写入文件，在需要时回查，这比完全依赖模型的“记忆”更可靠。
上下文窗口管理：当工具调用返回的结果非常庞大（如一整份财报）时，与其全部塞进有限的上下文窗口，不如让 Agent 将结果保存为文件，然后只将文件路径和摘要放入上下文。当后续步骤需要细节时，Agent 可以按路径读取文件。

2.2 “上下文工程”成为核心竞争力

“上下文工程”这个词精准地概括了 Agent 工程中一项至关重要的工作：如何高效地管理、组织和喂送给模型的信息。

想象一下，你让一个人类员工处理一个持续数天的复杂项目。你不会在他耳边不停重复所有项目细节，而是会给他一个项目文件夹（文件系统）、一份任务清单（规划）、以及定期的工作汇报机制（压缩与总结）。Agent 的上下文工程就是在做类似的事情。

一个优秀的 Harness，必须在以下方面做好上下文工程：

子任务管理与通信：主 Agent 如何将任务拆解给子 Agent？如何传递必要信息？如何确保子 Agent 返回的是“最终结果”而不是一句“请看上文分析”？（主 Agent 看不到子 Agent 的完整上下文）。
记忆的存储与检索：如何让 Agent 记住跨会话的重要信息？是基于向量数据库的语义检索，还是基于关键字的精确查找？
工具结果的过滤与摘要：调用一个搜索工具可能返回10个网页内容，如何提炼出对当前步骤最关键的一两句话？

目前，在 Harness 工程上做得最好的，往往是编程领域的公司（如 Claude Code、Cursor 等）。这是因为编程任务天然具有长序列、依赖性强、状态复杂的特点，倒逼它们在上下文工程上做到了极致。它们的成功并非仅仅因为模型强大，更是因为对“模型如何在特定 Harness 中工作”有着深刻理解。

2.3 从“Scaffolding”到“Harness”：开发体验的进化

Harrison Chase 将 Agent 的发展分为三个阶段，清晰地展示了工程重心的迁移：

早期（Scaffolding 阶段）：模型能力弱，需要大量外部代码（脚手架）来引导和约束其行为，流程僵硬。
中期（框架阶段）：模型支持工具调用和简单规划，开发者使用 LangChain 这类框架灵活组装组件，但整体流程仍需要大量定制。
当前（Harness 阶段）：模型能力足够强（特别是推理模型），通用的“LLM循环执行”算法变得可行。复杂性从“如何构建流程”的代码，转移到了“如何设计提示词和工具”的自然语言工程上。一个设计良好的 Harness 能让开发者更关注任务本身，而非底层运转机制。

小结：构建 Agent 应用，正在从“从零搭建一辆车”转向“在优秀的底盘（Harness）上组装功能模块”。上下文工程的能力，决定了你的 Agent 是只能处理三言两语的聊天机器人，还是能完成复杂多步任务的“数字员工”。

3. 长任务 Agent 的崛起：从“聊天”到“做事”

2025年末到2026年，被许多人视为“长任务 Agent 元年”。这里的“长任务（Long Horizon）”指的不仅是任务耗时久，更是指任务步骤多、决策分支复杂、需要持续规划和自我修正。

3.1 长任务 Agent 的典型形态

目前，最成熟的长任务 Agent 应用集中在几个领域：

编程 Agent：如 Claude Code、Cursor、GitHub Copilot Workspace。它们能理解一个模糊的需求（如“给这个API添加用户认证”），然后自主地创建文件、编写代码、运行测试、处理错误，最终提交一个可用的 Pull Request。
研究型 Agent：给定一个主题，它能自动搜索资料、阅读文档、分析数据、撰写结构化的研究报告初稿。
AI SRE（站点可靠性工程师）：当线上系统出现事故时，Agent 可以自动查询日志、分析指标、追溯根因，并生成初步的事故分析报告。
客服升级处理：当第一层自动客服无法解决问题时，不是简单转人工，而是启动一个后台 Agent，让它收集用户历史、查询知识库、生成完整的案情摘要，再交给人工客服，极大提升处理效率。

它们的共同点是：产出“初稿”。Agent 负责完成耗时、繁琐的信息收集、整理和初步加工，人类负责最终的审核、判断和决策。这是一种高效的人机协同模式。

3.2 为什么“文件系统”和“代码执行”是关键能力？

Harrison Chase 对此态度明确：现阶段，只要做长时序智能体，就必须给它文件系统的访问能力。原因如前所述，是为了上下文管理。而关于“代码执行”，他持有90%的赞同态度。

因为对于大量长尾、非标准的任务，“写一段脚本”仍然是通用性最强的工具。让 Agent 拥有一个安全的代码沙箱（Sandbox），能够执行它自己或他人编写的代码来验证想法、处理数据、调用复杂逻辑，这极大地扩展了其能力边界。相比之下，“直接操作浏览器”或“模拟鼠标键盘”等方式，目前稳定性和可控性都还不足。

3.3 交互模式：在“同步”与“异步”之间切换

长任务 Agent 改变了人机交互的范式：

异步管理是默认模式：你启动一个研究任务，让它跑上几个小时或几天。你需要一个“任务队列”或“看板”式的界面来管理多个并发的 Agent 任务，就像管理 Jira 工单或电子邮件一样。
同步介入是必要补充：当 Agent 遇到困难、产生疑问或完成初稿时，你需要能立刻切入，与它进行同步对话，给予指导或反馈。纯异步的“发了任务就等结果”模式，在 Agent 能力尚未完美的当下，体验并不好。

未来的 Agent 工作流界面，很可能融合了任务管理（异步）和聊天对话（同步），并且能实时展示 Agent 正在操作的“工作区”（Workspace）状态，比如它修改了哪些文件、生成了哪些图表。

小结：长任务 Agent 不再是“一问一答”的聊天机器人，而是能够独立负责一个完整工作流的“数字同事”。它的崛起，标志着 AI 从“对话式助手”向“执行式伙伴”的深刻转变。

4. 传统软件公司的生存考验：优势与陷阱

当工程范式从“确定性代码”转向“非确定性Agent”，那些依靠传统软件工程建立壁垒的公司，将面临前所未有的挑战。Harrison Chase 将之比作从“本地部署（On-prem）”软件转向“云（Cloud）”服务的时代——并非所有公司都能成功转型。

4.1 传统公司的潜在优势：数据与 API

传统软件公司最大的资产，往往是其深耕行业多年积累的专有数据和成熟的业务 API。在 Agent 时代，这些资产价值巨大。

数据价值：高质量、结构化的行业数据是训练垂直领域 Agent 或优化其提示词的宝贵燃料。一个金融软件公司的交易数据，一个医疗软件公司的病历数据，都是构建行业专属 Agent 的护城河。
API 价值：Agent 需要通过工具（Tools）与世界交互。传统软件公司已经将复杂的业务逻辑封装成了稳定、可靠的 API。将这些 API 暴露给 Agent，就能瞬间让 Agent 获得深厚的行业操作能力。

挑战在于：如何将数据和 API，与 Agent 的“使用说明书”（即高质量的提示词和指令）结合起来。过去，这些“说明书”存在于员工的头脑中或培训手册里；现在，需要将它们系统化、结构化，并“教会”Agent。

4.2 必须跨越的思维鸿沟

拥有资产不等于能用好资产。传统软件公司面临的核心挑战是思维模式的转变：

从“控制”到“引导”：传统软件追求绝对可控，每个分支都有对应代码。Agent 应用则要求你学会设定目标、提供工具和上下文，然后接受一定范围内的非确定性输出，通过评估和反馈来“引导”而非“控制”它。
从“离线测试”到“在线迭代”：传统开发依赖完善的测试套件保障上线质量。Agent 开发则更依赖上线后的真实数据、用户反馈和持续的在线评估来迭代优化 Prompt 和 Harness 设计。
团队技能重组：团队中不仅需要传统的后端、前端工程师，还需要“Agent 工程师”或“提示词工程师”。这些人需要深刻理解模型特性、精通上下文工程、擅长设计人机协作流程。Harrison 观察到，很多在 Agent 工程上走得快的团队，成员反而更年轻，因为他们没有传统开发模式的“历史包袱”。

4.3 新玩家的机会与“记忆”护城河

对于创业公司而言，这是一个巨大的机会。它们没有历史系统的负担，可以直接用最新的 Agent 范式来构建产品。例如金融领域的 Rogo，其优势就在于团队将深厚的金融行业知识直接融入了 Agent 系统的设计。

此外，记忆（Memory）可能成为 Agent 应用新的护城河。一个能记住用户长期偏好、历史交互习惯的客服 Agent，其体验会远远优于每次对话都从零开始的 Agent。这种记忆能力，使得 Agent 能够实现某种程度的“自我改进”——通过分析历史 Trace，自动优化自己的 Prompt 或行为模式。正如 Harrison 分享的自身经历：一个用了两年、带有记忆的邮件 Agent，其体验远优于一个功能相同但缺乏记忆的新版本。

小结：传统软件公司的转型之路，关键在于能否将自身的数据与 API 资产，通过全新的 Agent 工程能力（上下文工程、评估体系、人机协同设计）转化为产品竞争力。这是一场“硬件”与“软件”都需要升级的战斗。

5. 给开发者与团队的实践指南

面对 Agent 工程的浪潮，个人和团队该如何起步和深入？以下是一个从探索到实践的路径框架。

5.1 心态准备：接受非确定性，拥抱“初稿文化”

首先，调整预期。Agent 不是魔法，不能100%可靠地替代人类。将其定位为“初稿生成者”或“强力副驾”更为现实。接受它的输出需要人工审核、修正和润色。建立“初稿文化”，让人类专注于更高价值的判断、创意和决策，将重复、耗时的信息处理工作交给 Agent。

5.2 技能栈升级：超越编程

除了传统的编程技能，你需要有意识地培养以下能力：

提示词工程与迭代：学会如何清晰、结构化地定义任务，如何通过少样本（Few-shot）示例引导模型，如何设计 Chain-of-Thought（思维链）。
工具思维：思考如何将复杂能力封装成 Agent 可调用的标准化工具（函数）。设计良好的工具接口是 Agent 能力扩展的关键。
Trace 分析与调试：熟练使用 LangSmith 等工具，学会阅读和分析 Agent 的执行轨迹，从非确定性的行为中定位问题根源（是 Prompt 不清晰？工具返回异常？还是上下文混乱？）。
评估体系设计：为自己的 Agent 应用设计评估方案。是人工评分？还是构建一个校准过的 LLM-as-a-Judge？如何收集高质量的人类反馈数据？

5.3 开发流程变革：Trace 驱动的迭代

建立以 Trace 为核心的新开发流程：

原型构建：使用 LangChain、LlamaIndex 等框架或 Deep Agents 等 Harness 快速搭建 Agent 流程。
收集 Trace：用真实或模拟的数据运行 Agent，在 LangSmith 中完整记录执行轨迹。
分析与标注：和团队一起 Review Trace，找出决策错误、冗余步骤或低效环节。在关键步骤上添加人工标注（哪里好，哪里不好，应该怎么做）。
迭代优化：根据 Trace 分析，优化 Prompt、调整工具、改进 Harness 配置，甚至用标注过的 Trace 数据来微调模型或训练评估器（Judge）。
监控与持续学习：上线后，持续收集生产环境的 Trace，将其作为改进系统、构建记忆（Memory）的数据源。

5.4 团队协作：共享“Trace”而非仅“Code”

在 Agent 项目中，当讨论一个 Bug 或一个功能改进时，最有效的沟通媒介可能不再是 GitHub 的代码 Diff，而是一条 LangSmith 的 Trace 链接。团队需要建立基于 Trace 进行协作的文化，共同理解 Agent 在具体场景下的“思考过程”。

5.5 开始你的第一个长任务 Agent 项目

如果你从未接触过 Agent 开发，可以从一个具体的、有明确边界的长任务开始：

选择场景：比如“自动周报生成”。输入：你一周的日历事件、GitHub 提交记录、Slack 摘要。输出：一份结构化的周报初稿。
选择工具：从 LangChain 开始，利用其丰富的文档和社区。对于更聚焦的长任务，可以研究 Deep Agents 的设计。
设计流程：
- 规划：让 Agent 先规划周报的结构（工作总结、项目进展、下周计划）。
- 收集：调用工具（读取日历API、GitHub API）获取数据。
- 分析：让 Agent 对数据进行分析和总结。
- 撰写：根据结构和分析结果，生成报告草稿。
运行与调试：在 LangSmith 中运行，仔细观察每一步的 Trace。你会发现，Agent 可能会在“如何归类某个会议”上犯难，或者在总结代码提交时抓不住重点——这些都是你迭代 Prompt 和工具设计的切入点。
加入人工环节：设计一个流程，让 Agent 生成的周报初稿自动发送给你审核，你修改后确认发送。