一个对比开始

你在 ChatGPT 里问"什么是 KV Cache"，模型回答你，对话结束。

你在 Codex CLI 里说"给项目添加一个用户认证模块，包含测试"，agent 开始自主工作：读取项目结构 → 理解现有代码 → 规划实现方案 → 编写认证逻辑 → 编写测试 → 运行测试 → 发现失败 → 修复 → 测试通过 → 提交 PR。整个过程可能经历几十步，你可能全程没有介入。

同样的底层 LLM，完全不同的行为模式。前者是 LLM 的传统用法，后者是 LLM 的 agentic 用法。

这篇文章想讲清楚这个转变的本质——它不只是"模型变强了"，而是一种使用范式的根本变化，以及这个变化如何重塑了整个工程体系。

什么是 Agentic

Agentic 来自 agent（代理人/智能体）加形容词后缀 -ic，意思是"具有 agent 特性的"。

一个 LLM 如果只是一问一答，它就是一个工具——你用它，它不用你。但当 LLM 被放进一个循环中，让它自主地规划 → 决策 → 执行 → 观察 → 再决策，它就变成了一个 agent——它在为了你的目标主动工作。

具体来说，agentic 的 LLM 通常具备四个特征：

① 自主多步执行。 不是单轮对话，而是 agent 自己决定下一步做什么，持续执行直到完成目标。一个任务可能涉及 10 步，也可能 100 步。

② 工具使用。 模型不只生成文字，还能调用外部工具——执行 shell 命令、读写文件、调用 API、查询数据库、操控浏览器。LLM 的"手"从键盘延伸到了整个操作系统。

③ 环境感知与反馈循环。 Agent 能观察自己行动的结果——测试通过了吗？命令报错了吗？页面渲染对了吗？——然后根据反馈调整后续行动。这形成了一个闭环：行动 → 观察 → 推理 → 下一步行动。

④ 跨会话持续工作。 不是一次对话就结束，而是能跨越多个 context window，在几小时甚至几天内持续推进一个长期目标。

当这四个特征同时具备时，LLM 就不再是一个"聊天机器人"，而更接近一个"数字工程师"——有自己的工作循环、能使用工具、能感知环境、能持续推进。

从 Chat 到 Agent：不是渐变，是相变

这个转变不是线性的——不是"模型更强了所以能做更多事"。它更像是物理中的相变：水加热到 100°C 不是变成"更热的水"，而是变成了蒸汽——一种完全不同的物质状态。

LLM 从 chat 到 agent 也是这样。当模型能力跨过某个阈值（足够好的指令遵循、足够强的推理能力、足够可靠的工具调用），它就从"回答问题的工具"变成了"自主工作的实体"。这个转变带来了一系列连锁反应，改变了整个工程体系的形态。

工程师角色的变化

在 chat 范式下，工程师写代码，LLM 辅助（自动补全、代码审查、问答）。人是执行者，AI 是顾问。

在 agentic 范式下，工程师设计环境和约束，agent 执行代码编写。人是架构师和监督者，AI 是执行者。

OpenAI 在 Harness Engineering 文章中对此有一句精确的描述：人类引导方向，agent 执行。工程师的主要工作不再是写代码，而是设计环境、明确意图、构建反馈循环，让 agent 可靠地工作。

技术栈的演化

这个范式转变催生了三个逐层叠加的工程学科：

Prompt Engineering（2023-2024）。 核心问题：怎么问一个好问题。工具：system prompt、few-shot examples、CoT。比喻：学会怎么跟一个很聪明但很字面的同事说话。

Context Engineering（2025）。 核心问题：怎么给模型看正确的信息。工具：RAG、MCP、结构化 context 管理。比喻：不是教同事怎么做，而是给他准备好正确的参考资料。

Harness Engineering（2026）。 核心问题：怎么让 agent 在长期自主运行中保持可靠。工具：架构约束的 linter、CI 验证、可观测性反馈循环、权限控制、文档治理、entropy 管理。比喻：不是给同事准备资料，而是设计整个办公环境——工位布局、审批流程、安全规范、质检体系——让一整组同事可以在你不在的时候持续可靠地工作。

关键认知：这三层不是替代关系，而是叠加关系。 Prompt engineering 没有消失，context engineering 没有让 prompt 过时，harness engineering 也没有让前两者变得不重要。它们像地质层一样层层堆叠——每一层都是上一层的前提。

为什么 Prompt/Context “Hold 不住了”

一个很自然的问题：既然 prompt 和 context 还在，为什么说它们"hold 不住了"？

因为 agentic 的 LLM 带来了三个 prompt/context 无法单独应对的新挑战。

挑战一：操作的不可逆性

当 LLM 只是回答问题时，它最坏的结果是给你一个错误的答案——你看了不对，忽略就行。但当 agent 在自主执行时，它可以删除远程 git 分支、上传认证令牌到外部服务器、对生产数据库执行迁移。这些操作是不可逆的。

这不是 prompt 能解决的。你不能靠在 system prompt 里写"请不要删生产数据"来保证安全。你需要的是结构性的权限控制——在模型 context 之外的、确定性的拦截机制。Anthropic 的 Claude Code auto mode 就是这样一个机制：用一个独立的分类器在操作执行之前拦截危险行为，而且这个分类器故意被设计为看不到 agent 自己的推理过程，避免被 agent “说服"放行。

挑战二：运行时间与上下文退化

Chat 模式下，一次对话可能几分钟，几千 token。Agentic 模式下，一个任务可能运行几小时，跨越多个 context window，产生几十万 token 的上下文。

研究表明，context window 利用率超过约 40% 时，模型性能就开始退化——不是因为空间不够，而是因为信号被噪声淹没了。每多一个 token 都在争夺模型的注意力。agent 不是因为"忘了"而出错，而是因为关键约束被累积的历史信息掩盖了。

解法不是"给更多 context”（这往往让事情更糟），而是结构化的上下文管理——渐进式披露、层次化文档、定期的 context compaction、跨会话的进度文件。这些是 harness 级别的机制，不是 prompt 级别的。

挑战三：代码库的熵增

当 agent 自主生成大量代码时，它会复制代码库中已有的模式——包括坏模式。随着时间推移，代码库不可避免地累积不一致的风格、重复的逻辑、退化的架构。OpenAI 把这种现象称为 entropy（熵），并设计了 garbage collection 机制来对抗它——定期运行 agent 扫描偏差、发起重构 PR。

这也不是 prompt 能解决的。你需要机械化的架构约束（linter + 结构测试）和自动化的代码治理流程。

Agent 的核心循环

理解了 agentic 化的本质之后，我们可以看看 agent 的实际运作机制。不管具体实现如何，所有 coding agent 的核心都是同一个循环：

while 目标未完成:
    1. 观察（读取代码/文档/测试结果/错误信息）
    2. 推理（基于观察 + 目标，决定下一步做什么）
    3. 行动（执行工具调用——写文件/跑命令/调 API）
    4. 评估（检查行动结果——测试通过了吗？有报错吗？）

这个循环在 Geoffrey Huntley 的博客中被称为 Ralph Loop——一个单体 agent 在单进程中执行单一任务的循环迭代。他特别强调不要急于做多 agent——非确定性的微服务（即多个互相通信的非确定性 agent）是"一团糟"。

OpenAI 的 Codex 在这个循环的基础上，加入了完整的可观测性体系——让 agent 能看到应用运行时的 logs、metrics、traces，从而不仅能写代码，还能自主诊断和修复运行时问题。这形成了更大的闭环：写代码 → 部署 → 观测运行状态 → 发现问题 → 修复 → 再部署。

Agentic 化对你意味着什么

如果你是一个正在转型 AI 应用工程的后端工程师，agentic 化带来了两个层面的影响。

作为使用者：你的生产力工具正在变形

你用 Codex CLI 写代码的方式会越来越接近"管理一个下属"——描述目标、提供上下文、设定边界、审查产出。你的 AGENTS.md、项目文档结构、linter 配置、测试套件——这些不再只是"工程最佳实践"，而是你管理 agent 的核心工具。

写好文档的能力变成了生产力瓶颈——文档质量直接决定 agent 产出质量。系统设计能力变成了最核心的竞争力——你设计的架构约束越清晰，agent 工作越可靠。这恰好是后端工程师的优势所在。

作为建造者：你在构建的东西也在 agentic 化

你的 hey!stalker 项目——一个 Telegram ReAct agent——本身就是一个 agentic 系统。你正在解决的问题（记忆管理、工具调用编排、上下文工程）正是 agentic 化的核心技术挑战。

更广泛地看，市场上对"AI Application Engineer"和"AI Agent Engineer"的需求，本质上就是在招能够构建和运维 agentic 系统的人。理解 agentic 化的本质——不只是理论上知道，而是实际构建过 agent、踩过坑、知道 harness 为什么重要——这就是你的差异化竞争力。

未来的方向

Agentic 化还在早期。几个值得关注的方向：

Agent 的评估体系。 当 agent 自主生成代码时，怎么评估质量？Anthropic 的做法是让评估 agent 用 Playwright 实际操作生成的页面（端到端测试），而不是让另一个 LLM 读代码打分。生成和评估必须分离——agent 评估自己的工作永远是正面的。

多 Agent 记忆的可信性。 当多个 agent 共享知识库时，怎么防止幻觉或攻击污染共享记忆？已经有研究提出了类似区块链共识机制的方案——每个 agent 有声誉权重，提交的记忆需要加权投票验证才能写入。

Agent 的安全护栏。 Anthropic 刚发布的 Claude Code auto mode 展示了一个方向：用独立的分类器拦截危险操作，而且分类器故意对 agent 的推理过程不可见，防止被"说服"。两层防御（输入层的注入检测 + 输出层的行为分类）复合使用，使端到端攻击的难度远大于攻破任一单层。

Harness 的标准化。 AGENTS.md 已经成为 Linux Foundation 下的开放标准，被 60,000+ 仓库采用。harness 工程的核心组件——文档结构、架构约束、可观测性集成、entropy 治理——正在从"各家摸索"走向行业共识。

一句话总结

LLM 的 agentic 化不是"模型变强了"，而是"使用范式变了"——从被动回答到自主工作。这个转变让 prompt/context engineering 依然必要但不再充分，催生了 harness engineering 这个新的工程学科。对工程师来说，核心竞争力从"写代码的能力"转向了"设计让 agent 可靠工作的环境的能力"——而这恰恰是有系统设计经验的后端工程师最擅长的事。

参考来源：

  • OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World”, 2026.02
  • Anthropic, “Claude Code Auto Mode: A Safer Way to Skip Permissions”, 2026.03
  • Anthropic, “Effective Harnesses for Long-Running Agents”, 2025.11
  • Geoffrey Huntley, “Everything is a Ralph Loop”, 2026.01
  • Mitchell Hashimoto, Harness Engineering concept, 2026.02
  • Softmax Data, “From Prompt Engineering to Harness Engineering: The Three Eras”, 2026.03