从 Tool Agent 到 Harness Engineering：一个 Agent工程师的升级路径

1. TL;DR

Agent 的瓶颈，不在模型，也不在工具，而在有没有一个能持续做事的 Runtime。

大多数 Agent 还停在 tool 层，而真正能跑长任务的系统，本质上已经进入了 Harness Engineering：

用一套可持续、可恢复的 Workspace Runtime，让 Agent 在“现场”中工作，而不是在 prompt 里拼世界。

当你在想如何将你简单的 Agent 调用升级成一个拥有自己Runtime，具备Harness Engineering特点的 Agent，又不想引入 docker，Sandbox 这些复杂、沉重的运行环境，这篇文章值得你阅读。

2. 为什么大多数 Agent 很难持续完成复杂任务

3 年前，我刚开始写 Agent 时，路径其实很简单：

• 先写一个 prompt
• 接几个 tools
• 简单任务就已经能完成

一开始，这种方式效果很好。

但只要任务进入多轮执行、持续修改和长链路推进阶段，问题就会很快出现：

• 上下文越来越长，prompt 越来越难维护
• 状态经常丢失，每轮都要重新喂信息
• 任务做到一半就“断片”，下一轮只能猜之前发生了什么
• Agent 看起来很聪明，但多轮任务后性能会明显下降

后来，我开始把 memory 拆出去，试图把“上一次任务状态”和“下一次任务状态”做剥离，只保留摘要和关键结论。

这样做确实有帮助：

系统短时间内会更稳定，token 压力也会下降。

但新的问题很快出现了。

为了让 Agent 在特定场景里表现稳定，我开始不断把能力做成更细的 workflow、摘要结构和状态槽位。这样做在一些垂直任务里效果不错——只要场景足够明确，专门设计一套 Agent Workflow，通常都能达到不错的水准。

但一旦任务变成类似 Coding 这种需要 Agent 综合思考、持续探索、动态修正的工作，问题就会暴露得非常明显：

• workflow 越做越细，泛化性越差
• memory 保留的是摘要，不是现场
• Agent 拿到的是“别人整理过的过去”，而不是“自己正在工作的现在”
• 它可以知道之前做过什么，却很难自然地接着做下去

---

3. 我从 Manus 到 Claude Code，真正学到的不是 Workflow，而是 Runtime

从去年年初的 Manus 的大火，到后续的 Claude Code 类型的 vibe coding 工具横扫编程界，我意识到：

真正能跑复杂任务的 Agent，背后一定有一个持续存在的 Runtime。

我不应该把 Agent 定位在一个子任务的完成，而是发挥 Agent First，让 Agent 自己去探索如何完成任务。不再要求 Agent 一次性能生成一个完美的结果，而是允许 Agent 做阶段的产出，再逐步把阶段性的产出变成我期望的结果。

这和我早期做 Agent 时的思路很不一样。

以前我更容易把问题理解成：

• prompt 不够强
• tools 不够多
• workflow 不够细
• memory 不够聪明
• 人类可以告诉 Agent 你需要的上下文是什么

Coding Agent 真正强的地方，不只是“会调用工具”，而是它们让 Agent 有了一个可以持续做事的环境。

在这样的系统里，Agent 不再只是一次次发起调用，而是在一个稳定的工作现场里推进任务：

• 可以查看已有文件
• 可以记录中间想法
• 可以拆解任务和保存计划
• 可以持续修改结果
• 可以根据反馈继续往下做
• 可以在中断后回到之前的现场

通过这些 Runtime 里的反馈，Agent 可以自己决定自己需要哪些上下文，去完成任务。

传统 Agent 要升级到 Harness Engineering，关键不是把 workflow 继续做复杂，而是给 Agent 引入 Runtime。

而如果想用一种足够轻、足够自然、又足够容易落地的方式完成这次升级，文件系统几乎是最合适的起点。

原因很简单。

文件系统天然就能承接 Agent 持续工作所需要的几个核心能力：

• 文件可以保存中间状态
• 目录可以组织上下文和材料
• notes 可以记录想法和计划
• patch 可以支持持续修改
• workspace 可以作为任务现场长期存在

也就是说，一旦 Agent 不再只面对 prompt 和 tool call，而是开始围绕一个文件工作区做事，它就已经开始从传统 Agent 走向 Harness Engineering 了。

"Harness"本意是马具——缰绳、鞍具那一套东西，把马的力气引到正确方向上。拿来类比 AI Agent 挺合适：Agent 就像一匹蛮力十足但方向感不太行的马，跑得快但容易跑偏.

如何约束 Agent 跑得快，又不跑偏，我们不得不让 Agent 本身就处于一个具体的 Runtime 中。在代码领域，就是要让 Coding Agent处于一个确定的项目里。项目本身代码，文件就是这个项目要做什么的最好说明。那如果任务不是代码呢？

那它需要的是不是一个它完成任务所需的所有文件资料的环境？然后交给 Agent 自己在里面逐步摸索出最终结果。

在 Coding Agent 上已经证明了这是可能的。只是我如何在服务器上构建这样的文件系统，可以同时提供给无数用户使用。面对这个问题我开始了思考。

4. 升级的本质：从 Tool 到 Runtime

当我开始接受一个事实：

Agent 需要的是 Runtime，而不是继续堆 workflow。

接下来，一个更现实的问题就出现了：

这个 Runtime 到底应该长什么样？

一开始，我也尝试过走一条更“标准”的路径，学习 Claude Code 的做法：

• sandbox / Docker
• 完整 shell 环境
• 可执行脚本 + 测试系统

这套方案在很多 coding agent 场景里当然成立。

如果你的目标是执行代码、安装依赖、启动服务、跑测试，那么给 Agent 一个完整的隔离环境，几乎是最直接的选择。

但很快我就发现，这条路对大多数场景来说太重了。

我自己的体感非常直接：

一台 2 核 2G 的轻量级服务器，在传统互联网服务里，承载十几个人同时使用，通常不会有太大压力；但一旦引入 Docker，系统负载很快就会变得吃紧。对很多并不需要完整执行环境的任务来说，这种成本并不划算。

更麻烦的其实还不是性能，而是状态。

如果 Agent 的工作现场放在 sandbox 里，就会立刻遇到几个很现实的问题：

• 用户在 sandbox 里的数据，怎么低成本保存？
• 容器被释放之后，之前的工作现场怎么恢复？
• 怎样保证中间状态和最终结果的可靠性？
• 如果只依赖轻量服务器本地磁盘，真的值得信任吗？

我很快就意识到，问题的关键不是“要不要容器”，而是：

用户数据不应该和容器生命周期绑在一起。

容器可以是执行载体，但不应该是状态真值。

我不愿意把用户真正重要的中间状态、草稿、上下文、计划和结果，直接压在某个随时可能重建、迁移或释放的 sandbox 里。

于是我开始换一个方向思考：

有没有可能把文件保存在数据库里，但让 Agent 感知到的仍然是一个文件环境？

这个想法对我来说是一个很重要的转折点。

因为它意味着，我不再把问题理解成：

• 如何给 Agent 一个完整容器
• 如何让 Agent 拥有真实 shell
• 如何把宿主系统尽可能搬进 sandbox

而是开始把问题理解成：

• 如何给 Agent 一个稳定的工作区
• 如何让这个工作区的状态脱离容器生命周期
• 如何让文件现场可持久化、可恢复、可回写
• 如何让 Agent 感知到的是“文件系统”，而底层真实承载的是更可靠的持久化结构

换句话说，我真正想要的，其实不是一个“完整系统”，而是一个足够像文件系统的 Runtime：

• Agent 可以像操作文件一样工作
• 用户数据可以像数据库一样可靠保存
• 工作现场可以独立于容器存在
• 系统可以在轻量机器上更低成本地运行

这时候，文件系统就不再只是一个工具接口，而开始变成一种 Runtime 形态。

它的价值不只是 read / write，而是它天然能承接任务持续推进时最需要的那几样东西：

• 文件可以保存中间状态
• 目录可以组织上下文和材料
• notes 可以记录想法和计划
• patch 可以支持持续修改
• workspace 可以作为任务现场长期存在

也正是从这里开始，我越来越明确一件事：

对于大量 editing-style Agent 来说，最需要的不是一个重型 sandbox，而是一个轻量、可持久、可恢复的文件工作区 Runtime。

而这，也正是后面 Iruka_VFS 诞生的起点。

---

5. 从“会调工具”到“在工作区里做事”

当引入 workspace 之后，Agent 的行为会发生一个非常关键的变化。

在传统 Tool Agent 里，Agent 的行为是这样的：

• 想一步
• 调一个 tool
• 拿到结果
• 结束

但在 Workspace Runtime 里，行为变成：

• 查看当前工作区
• 修改某个文件
• 记录中间想法
• 根据结果继续调整
• 反复推进

也就是说：

Agent 不再是在调用工具，而是在一个环境里工作。

这个变化会带来一系列连锁反应：

5.1 思考从“瞬时 token”变成“可沉淀对象”

• 不再只是输出在 response 里
• 可以写入 /notes
• 可以被后续步骤引用

5.2 上下文从“拼接”变成“引用”

• 不需要把所有信息塞进 prompt
• 直接读取文件
• context window 压力显著下降
• Agent 可以根据自己需求构建自己的上下文，而不是基于规则构建

5.3 修改从“整段重写”变成“局部演进”

• edit / patch 替代 rewrite
• 可以围绕同一份材料反复优化
• 错误可以局部修复

5.4 状态从“记忆”变成“现场”

• memory 记录的是“过去”
• workspace 保留的是“现在”

5.5 任务从“流程执行”变成“持续收敛”

• 不再依赖预定义的 workflow
• 可以动态调整路径
• 更接近真实人类工作方式

---

6. Iruka_VFS：把 Workspace Runtime 变成工程能力

理解到这一点之后，我做了一个决定：

不要再继续扩展 toolset，而是把 workspace 本身做成一层 runtime。

这就是 Iruka_VFS 的出发点。

它解决的不是“如何读写文件”，而是：

如何让 Agent 拥有一个可控、可持续、可恢复的工作区。

具体来说，它做了几件关键的事情：

6.1 把宿主对象投影成统一工作区

无论宿主系统里是：

• 文档
• 数据
• 配置

都会被映射到：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
/workspace
/files
/notes
/context
/skills
AGENT.md

这样 Agent 面对的是统一结构，而不是业务碎片。我完全重写了 Bash 命令里所有跟文本操作的指令。因此，Agent 在里面的操作也是正常的 Bash 命令语法，Agent的理解不会有任何语义差别。就像 Claude Code 在你电脑上运行一样。只是 Agent 是在一个虚拟的文件环境下进行。因此这一切操作也不会干扰到服务器上真实的文件。

6.2 用 RuntimeSeed 定义工作区启动

每次任务启动时，只需要定义：

• 文件目录结构
• context
• skill
• metadata

就可以构建一个完整工作现场。根据业务的需求，可以构建业务上所需的任何目录结构，然后把必要的文件信息写入到目录里对应的位置，方便 Agent 自己理解，然后执行。

6.3 用工作区替代“拼接上下文”

不再依赖：

• prompt 拼接
• memory 重组

而是：

• 直接基于文件工作（看起来是文件系统）

Agent 可以自由的执行任何文本操作的 Bash 命令。可以使用 echo、edit将自己短期的工作结果，规划写入本地文件。通过 cat读取自己需要的文件内容，也可以通过 grep，rg 命令进行搜索。所有这一切执行过程也会用日志记录下来，Agent 回顾时也不会有理解歧义。

6.4 用 edit / patch 替代 write

重点不是覆盖写入，而是：

• 局部修改
• 可回滚
• 可恢复

6.5 用 mirror + checkpoint 支撑运行时

• 内存镜像保证性能
• checkpoint 保证恢复
• flush 定义持久化边界

为了保证 Agent 执行性能，加入了缓冲层。数据会异步的写回数据库做持久化。缓冲层则使用分布式缓存中间件保存。保证用户即使访问不同的数据库，看到的文件内容，Agent 执行结果都是完全一致的。因此在面临横向扩展上也有着独到的优势，不用关注长连接需要关闭等网络问题。

---

7. 它和 Tool / Workflow / Sandbox 的区别

这一层可以用一句话总结。

相比 Tool Agent：

从“离散动作” → “连续工作”：拥有完整 Runtime，对于一个任务状态本身的上下文，可以持续演进。

相比 Workflow Agent：

从“预定义流程” → “动态推进任务”：Agent First，一切的决策权都交给 Agent 来决策。

相比 Sandbox：

从“完整系统” → “最小可用工作区”：阉割了代码执行能力，大幅降低了系统压力，可以更专注于文本处理任务。这也是最常见的任务类型。

这也是它所在的位置：

Toolset 和 Sandbox 之间长期缺失的一层。

---

8. 总结

真正的 Agent，不是“会调用工具”，而是“能在一个 Runtime 中持续做事”。

尤其对于文本处理的任务，这个 Runtime 最自然的形态就是：

Workspace Runtime

Iruka_VFS 所做的事情，就是把这个 Runtime 明确建模出来。

具体的技术实现，我会在后一篇文章中详细介绍。

你不是缺工具，你是缺一个让 Agent 持续工作的环境。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】