原文发布于我的博客： https://blog.hikarilan.life/thinking/3499/treating-llms-as-humans/

从 2022 年底 GPT 横空出世到现在，大模型的各项指标都产生了质的飞跃：上下文窗口从 64K 飙升至 1M 以上，多模态能力从纯文本演进到可以秒懂复杂的图像与视频。然而，基座大模型能力的不断提升，正在揭示一件让工程师们既兴奋又抓狂的事情——LLM 在行为表现上越来越像人类了。

随着“力大砖飞”的基座大模型逐渐展现出强大的原生规划能力，行业内开始出现一种声音，甚至以 Anthropic 为首的一些前沿组织开始抛出“Agent 工程无用论”，认为基座模型最终可以不依赖任何外部工程约束解决所有问题。

但现实恰恰相反。无论基座 LLM 如何发展，在智械彻底代替人类的全部工作之前，“把 LLM 当成人类看待，顺应人类的认知心理学与行为学去设计系统”，将永远是任何 Agent/Harness 工程走向成熟的进阶起点。

认知对齐：把 AI 当作你的“技术实习生”

如果你初次和 LLM 打交道，不知道该如何向它描述需求，那么“将 AI 视为技术实习生（Using AI as a Tech Intern）”一定是一个绝佳的思维模型。

传统的面向代码编程，我们习惯于给出确定性的绝对指令。但面对 LLM ，你需要把它当作一个拥有无限技术理论知识、但对你的具体业务、历史代码和上下文一无所知的新员工。对待实习生，你显然不会只丢下一句“帮我重构一下这个前端页面”然后转头离开；你需要做的是带他熟悉环境。在 Agent 工程中，这意味着我们需要抛弃简单粗暴的单句 Prompt ，转而为 Agent 建立一套详尽的“工作手册”，提供给 Agent 足够的业务背景和执行标准信息，帮助 Agent 锚定你的最终需求。

记忆解耦：工作记忆与长期记忆的硅基映射

在长文本大模型普及后，许多开发者产生了一个路径依赖：喜欢将成千上万行的 API 文档、整个项目的源代码一股脑塞进大模型的上下文窗口。这种“信息轰炸”看似省事，实则对模型的长文本召回毫无益处。

人类的认知心理学表明，人类的工作记忆（ Working Memory ）容量极其有限。我们在写代码时，绝对不会一边盯着屏幕，一边在脑海里反复背诵整本《 Java 核心技术》。人类靠的是注意力焦点——只看眼前的逻辑，遇到不确定的类名或 API 时，才会去查阅文档。大模型的上下文窗口，本质上就是它当前的工作记忆，而不是它的知识库。真正高级的 Agent 工程，应该学会帮大模型做“认知卸载（ Cognitive Offloading ）”，在上下文窗口中仅保留最核心的工作记忆，而将海量数据交给外部架构管理。

[海量历史上下文 / 业务文档]
       │
       ▼ (知识抽取与向量化)
┌────────────────────────┐
│  长期记忆 (Vector DB)   │ ◄─── (利用 mem0 等框架动态唤醒)
└──────────┬─────────────┘
           │ (仅检索当前任务相关的 Top-K 碎片)
           ▼
┌────────────────────────┐
│  工作记忆 (LLM Context) │ ───► [生成当前决策 (Action)]
└────────────────────────┘

通过这种记忆解耦设计，Agent 既不会被海量噪声信息淹没注意力，又能随时在需要时通过检索“唤醒”长期记忆。

感知层革新：人类依赖视觉，而非结构化源码

在自动化测试或 Web 开发 Agent 领域，很多工程师会陷入一个误区：坚信结构化的文本数据（如 DOM 树、Page Source ）一定比像素图像更精准。然而，这导致许多 Coding Agent 开发出的前端页面经常出现惨不忍睹的错位和布局问题。

为什么 DOM 树会“欺骗”大模型？因为 CSS 的自由度太高，且 DOM 树中充斥着大量不可见的 div 、埋点属性和动态加载的噪声。人类在肉眼排查前端 Bug 时，看的是渲染后的视觉界面，而不是硬啃上万行的 HTML 源码。让大模型在密密麻麻的 DOM 树里凭空“组装”出页面样式，无异于盲人摸象。因此，现代 Agent 工程应当顺应人类的感知习惯，将“视觉感知”提到第一优先级。例如，在进行 UI 自动化测试时，优秀的 Agent 工程不再向大模型提供冰冷的 DOM 节点，而是利用 Playwright 捕获当前页面截图，让多模态大模型直接“看图说话”，下达指令（对这方面感兴趣的朋友可以参考字节跳动的 UI 自动化测试框架 Midscene 是如何实现的）。

这种“所见即所得”的视觉模式，远比让 Agent 在脑内脑补 DOM 树要直观、高效得多。

工具生态：顺应大模型的“原生职业习惯”

大模型作为生产力工具，最成功的落地场景毫无疑问是“写代码”。全球的训练团队都在使用海量的代码语料、技术文档和开源项目来对模型进行强化对齐。这导致了一个奇妙的结果：每一个顶尖的基座 LLM ，天生就是一名极其优秀的程序员。

既然大模型拥有极高强度的“程序员职业常识”，我们在为它设计 Agent 工具链时，就应该给它提供人类程序员最熟悉的工具（如 Bash 、Git 、Markdown ），而不是工程师自创的、需要额外学习的自定义 Function Call 。例如比起 OpenCode 提供 grep / read 等 function call 读取文件内容、Codex CLI 在不同 OS 中采用其本地的 Shell 指令（ Windows 下是 pwsh ，macOS/Linux 下是 bash ）读取文件内容，Claude Code 选择为所有 OS 平台建立统一的 Shell 环境，在 Windows 下使用 Git Bash 而不是 pwsh 指令读取文件，这种统一性使得模型不需要针对不同平台使用不同的指令，且其使用的指令永远是程序员和其预料中最熟悉的那套东西。

将大模型当成真正的程序员，允许它像人类一样通过标准的开发者工具与系统交互，能让它在重构、Debug 和版本控制时激发出百分之百的原生代码天赋。

行动与反馈：构建容错的“闭环试验场”

根据热力学第二定律和熵增理论，如果一个系统在没有任何外部干预的情况下孤立运行，其内部质量最终一定会走向崩塌。Agent 工程也是如此——如果你只给大模型提要求，却不给它提供运行结果的反馈，那么随着步骤的加深，它最终一定会陷入幻觉和代码腐烂的泥潭。

人类工程师不可能写出永远不需要编译和 Debug 的代码。我们之所以能交付合格的系统，是因为我们拥有一个“编写-> 编译报错 -> 查看日志 -> 修改代码”的动态试错闭环。

因此，Agent 进阶的核心不在于写出多么完美的初始 Prompt ，而在于构建一个强大的 Harness （测试/运行基座）工程，为 Agent 提供稳定、硬性、具备高容错度的环境反馈。

	┌────────────────────────────────────────┐
    │          Agent 产生决策 (Action)        │
    └───────────────────┬────────────────────┘
                        │ (执行代码 / 操作 UI)
                        ▼
┌────────────────────────────────────────────────────────┐
│             Harness 工程 (硬门禁/环境反馈)               │
│  - 自动运行 Linter & Compiler (捕捉编译期错误)          │
│  - 执行自动化测试单元 (Runtime/Jest/JUnit)             │
│  - 捕获标准输出与 Crash Logs                           │
└───────────────────────┬────────────────────────────────┘
                        │
                        ▼ (将具象的错误日志作为 Context 返回)
    ┌────────────────────────────────────────┐
    │          Agent 结合反馈自我反思          │
    └────────────────────────────────────────┘

在这种硬门禁的闭环里，哪怕大模型第一遍写出了有 Bug 的代码，Harness 基座也会像一位严格的导师一样把 NullPointerException 和编译日志甩在它脸上，引导它通过自我反思完成修正。

先谋后动：引入 SDD 规避“盲目敲键盘”的低级错误

很多开发者在设计 Coding Agent 时，最常犯的错误就是让 Agent 看到需求后“立刻开始改代码”。这种“拿来就写”的行为，哪怕在人类工程师中也是低水平的体现，必然导致代码耦合度高、QPS 限制没考虑、逻辑四分五裂。

在高级 Agent 工程中，我们必须强制引入 SDD （ Spec-Driven Development ，规格说明驱动开发） 的工作流。这套流派的思想完全借鉴自资深人类架构师的思考路径：在动手写任何一行代码之前，必须先明确规格与计划。

市面上的 SDD 框架非常多，但所有的框架都包含生成 spec 、plan 、tasks 的机制，同时，这些框架也都不约而同地强调测试驱动开发（ Test-Driven Development ）的重要性，因为这可以为大模型带来确定性，用测试通过率告知 Agent 其功能实现的质量。

通过 SDD ，我们成功将大模型的行为从“直觉式的快思考”硬生生拉回了“逻辑严密的慢思考”，彻底根治了 Agent 盲目修改代码引入新 Bug 的顽疾。

结语

把 LLM 当成“机器”的开发者，往往止步于编写冗长复杂的 Selector 和堆砌 Function Call ，最终在模型幻觉的泥潭里痛苦挣扎；而把 LLM 当成“人类”的开发者，则会致力于为它构建完美的感知层、科学的记忆层、顺应直觉的工具链以及严苛的环境门禁。

不要再试图用传统的二进制思维去束缚那个渴望像人类一样思考的硅基大脑。给它一双眼睛，给它一套 Git 命令行，在它动手前要一份 Spec ，在它犯错时丢给它一份 Trace Log——这，才是 Agent 工程真正通往高阶的必经之路。

（此篇文章部分内容使用了 AI 技术进行润色，敬请理解）