智能体重塑软件工程角色：从编码者到平衡态设计师

如果你查看现代数据平台的提交历史，就会发现过去两年间发生了某种深刻的转变。编写语法的摩擦力已经崩塌。随着 Cursor、Claude Code 和智能体（agentic）工作流如今已嵌入我们的 Docker 容器和 IDE 中，生成分布式流式处理管道或复杂 API 集成的首个实现，已不再是核心瓶颈。

智能体能够导航代码仓库、编写测试覆盖、检查堆栈跟踪并提出重构建议。用平实的英语描述一个 Kafka 到 Iceberg 的 sink 映射，智能体便能在工程师打开所有相关文件之前，产出一个可信的起点。

这改变了软件工程师所面对的问题。

如果智能体正日益成为本地系统逻辑的主要作者，那么工程师究竟还剩下什么工作可做？我们是否正走向一个由评审者不断盖章批准一连串看似合理却永无止境的拉取请求（pull request）的行业？抑或工作重心已从构建逻辑转向某种更抽象的任务？

要回答这个问题，借用热力学的视角会有所帮助；该视角为我们提供了描述定向功、反馈、损耗以及维系复杂系统一致性的边界的语言。

作为热机的智能体

当我们剥离人工智能拟人化的幻觉后，剩下的便是一个计算引擎。它接收指令，并将其转化为行动。

位于数据中心中的大语言模型（LLM）拥有巨大容量，但在获得意图之前，它不会执行任何有用的工作。提示词（prompt）、业务需求、系统指令或一个失败的测试，都会为智能体提供方向。它将该方向转化为代码、工具调用、查询、测试以及对运行中系统的更改。

每台引擎都有损耗，每个智能体循环亦然。

任何曾让智能体在困难的代码仓库中持续运行过的人，都见过这种情况：它始于一项明确的任务；随后遵循一个过时的假设，仅修复表象而非根源，将旧的迁移操作误当作当前行为，并开始累积自身的历史。几次工具调用之后，上下文已包含足够多看似合理却彼此冲突的细节，致使下一步的确定性低于第一步。

我们将此称为操作熵（operational entropy）：在一个仍试图向前推进的循环内部，过时假设、分支化上下文及未解决依赖关系的持续累积。

人为干预之所以有效，是因为它引入了新信息；一个失败的测试、一份精确的数据契约、一个确定性的工具，或是一份明确指出智能体错误之处的评估报告，同样如此。若缺乏此类信号，智能体可能持续生成输出，同时却愈发偏离正确结果。

智能体显然能产生运动。真正的问题在于，其周围的系统能否将这种运动转化为有用功。

无限猴子与加速扩张的搜索空间

《 无限猴子定理 》为我们描绘了一幅有用的图景：反复尝试、有限约束与反馈。

该定理指出，一只猴子在无限长的时间内随机敲击键盘，几乎必然能打出莎士比亚全集。现代智能体是聪明得多的猴子：它们拥有编译器、工具、代码仓库、测试套件及反馈回路。其工作并非随机——反馈会引导下一次尝试——但其动态模式却十分熟悉：提出方案、执行、观察、修正、再次尝试。

在边界明确的任务中，该循环效果显著。

给智能体一个已知的输入模式（input schema）、一个已知的目标模式（target schema）、一个小型代码库，以及能捕获相关失败的测试，它便能检查代码、做出修改、运行测试、吸收结果并再次尝试。完成的定义清晰可见，搜索空间狭窄，该循环有机会收敛。

但企业级系统极少提供这种静止状态。实时定价引擎可能依赖于易变的运行时状态、第三方 API、延迟到达的事件、区域政策，以及部分存在于代码中、部分存在于某人头脑中的业务规则。数据湖仓（data lakehouse）在物理层面可能保持一致，语义上却可能是错误的。一条流水线可能通过全部测试，却仍产出财务部门无法识别的数字。

当猴子正在打字时，环境本身正在变化。

企业逻辑的三体问题

这正是为什么 三体问题 是理解企业级软件的一个极佳隐喻。

对于两个天体——一颗行星与一颗恒星——你可以用简洁的数学描述预测其运动。加入第三个天体后，问题便变得难解得多：不存在通用的闭式解，某些构型甚至表现出混沌行为。某处的微小变化，可能在别处引发截然不同的轨迹。

现代数据平台具有相同的结构：点击流数据随产品行为而变化；运营数据库在客户活动下发生变异；API 施加速率限制并更新版本；模式（schema）持续演进；安全策略不断调整；遗留系统承载着多年埋藏于异常处理逻辑中、无人书面记录的规则。

每个系统都在对其他系统施加压力。某处的变化会改变另一处的含义或行为。一个起初仅为局部的功能请求，最终可能牵动整个系统。

试想一个假设场景：智能体被要求向营收模型中添加一个 customer_tier 字段。它在运营数据库中找到一个名为 status 的字段，将其映射至转换逻辑中，并通过了既有的类型与空值性（nullability）测试。代码整洁，流水线呈绿色，答案却仍是错误的。

一份语义数据契约（semantic data contract）规定：customer_tier 应基于过去十二个月的消费额推导得出，须指定业务负责人，且不得从账户状态（account status）填充。该契约在变更抵达仪表板前即拒绝了该改动。工程师的贡献并非转换逻辑本身，而是设定了使智能体错误变得可见、具体且可恢复的边界。

新使命：设计平衡态

软件工程师的工作已不再是要编写每一处微观逻辑。智能体将越来越多地承担这项工作，且往往更快。新使命——设计平衡态——是创造一种条件，使得生成的逻辑值得信赖。

当业务需求变化的速度快于智能体吸收反馈的速度时，工程师必须构建约束场（containment fields）。严格的语义层、不可变事件日志、数据契约、幂等 API 及确定性状态机，绝非仅仅是良好的平台卫生实践；它们减少了智能体需同时做出的假设数量。

它们将一个耦合问题转化为一个具有明确输入、显式规则与可靠反馈的有界领域（bounded domain）。

一旦该领域建立，智能体便真正变得强大：它可编写转换逻辑、执行测试、修复失败项，并交付变更，而无需推断每张表与每项服务背后那些未曾写下的历史。

随着代码生成成本降低，软件工程的价值并未消失——反而变得更加可见；而这才是真正重要的转变。

自主系统将越来越多地生成软件。但决定这些软件是取得成功还是陷入混乱的合同、反馈回路和边界，仍将由软件工程师设计。

阿南特·帕克基尔杜赖（Ananth Packkildurai）是一名数据工程领导者、作家，也是《数据工程周刊》（Data Engineering Weekly）的作者，分享有关现代数据平台、大规模数据管道以及AI驱动架构的见解。