本文通过一个最小版本的Agent实现，深入浅出地解析了大模型的核心逻辑，即“读用户任务、让模型选择下一步、按模型要求调用工具、把工具结果喂回去继续循环”。文章强调了Harness在Agent运行控制系统中的核心价值，以及工具调用、记忆系统和权限分级策略的重要性。通过对比Claude Code、Pi框架和OpenClaw等成熟框架，揭示了它们在最小Loop基础上增加的工程化边界，如工具边界、上下文边界、记忆边界、权限边界和验证边界。最后，文章指出Agent工程的核心是“跑稳”，并鼓励开发者从最小版本入手，逐步完善Agent的工程化细节，使其成为可信赖的协作工具。

1、核心结论速览

如果赶时间，本文核心结论可浓缩为一句话：Agent起步靠一个循环，模型看上下文、选工具、拿观察、继续下一轮，几十行代码就能跑起来；但“能跑”和“能用”之间，差的全是循环外面的各类边界，Claude Code、OpenClaw、Harness等框架做的核心工作，就是补齐这些边界。

结合实践经验，有几条明确的结论的可直接参考：

• 大模型本身不具备执行文件读写、命令运行、网页搜索的能力，这些实际动作都由模型外部的运行系统完成，模型仅负责决策与指令输出。

• Function Calling的核心作用是“解决工具调用的表达问题”，它不会自动处理参数校验、权限控制、输出裁剪和错误恢复，这些均需额外的工程化设计。

• 记忆系统的核心目标不是让Agent记住所有内容，而是让它在合适的时机，精准召回对当前任务有用的信息，避免冗余与干扰。

• Harness不是可有可无的装饰层，它的核心价值是将一个能跑的Loop，改造为可恢复、可审计、可约束、可验证的稳定系统，决定Agent能否长期可靠运行。

• 最核心的一句话总结：最小循环让Agent动起来，Harness决定它能不能长期稳定地干活。

2、手搓目标：最小Coding Agent

明确一点：我们不可能在30分钟内复刻Claude Code这样的成熟产品。一个完整的Coding Agent，需要具备读仓库、改代码、跑测试、管理上下文、派发subagent、做compact压缩、处理权限等一系列能力，其外部的运行系统非常复杂。如果硬要从零打造完整版本，很容易做成一个“玩具版”的虚拟Claude Code，无法触及Agent工程的核心逻辑。

因此，本次手搓的核心目标的是“最小Coding Agent”，我们将目标高度聚焦，只保留最核心的输入、工具和逻辑，具体设定如下：

三类核心输入

最小Agent的运行，仅需要三类输入即可启动，无需复杂的配置与依赖：

• 用户任务：即开发者交给Agent的具体需求，比如“查看当前目录下的文件列表”“读取某个代码文件的内容”。

• 当前对话历史：包含用户任务、模型之前的响应、工具执行的结果等，用于模型判断下一步动作，形成循环。

• 工具列表：Agent可调用的工具集合，本次仅保留最基础、最可控的3个工具，不添加复杂工具增加实现难度。

三个基础工具

为了保证最小闭环的可控性，我们暂不添加写文件、删除文件等风险较高的工具，仅保留3个只读和有限执行类工具，具体如下：

• list\_files(path)：列目录工具，用于查看指定路径下的所有文件和文件夹，帮助Agent了解当前环境。

• read\_file(path)：读文件工具，用于读取指定路径下的文本文件内容，让Agent获取所需的文件信息。

• run\_command(command)：命令运行工具，仅允许运行白名单内的命令，避免无限制执行命令带来的风险。

这样的选择看似保守，却更贴近实际工程实践：新系统的第一版，优先让模型“观察环境”，再允许它执行少量可控动作；写权限、删除权限、网络权限、凭证访问等更敏感的能力，可在后续版本中逐步添加、逐步验证。这也是实战中很容易被忽略的第一层边界：Agent的能力不是越大越好，能力的扩展必须与验证、回滚机制同步推进，否则很容易引发安全风险与运行失控。

3、最小闭环：Agent核心逻辑（20行代码）

Agent的核心逻辑其实非常简单，就是一个循环（Loop）。下面这段代码不是完整的生产级代码，而是将Agent Loop的骨架提炼出来，20行左右即可看懂，能清晰呈现Agent的运行流程：

async functionrunAgent(task: string) {
constmessages = [
{ role: "user", content: task },
];
for (let step = 0; step < 8; step++) {
constresponse = await model.create({
messages,
tools,
});
messages.push({
role: "assistant",
content: response.content,
});
if (!response.toolCall) {
return response.text;
}
constobservation = await runTool(response.toolCall);
messages.push({
role: "tool",
content: observation,
});
}
return"Stopped: step limit reached.";
}

这段代码的逻辑非常清晰，核心就是5个步骤的循环往复，直到完成任务或达到步数限制：

1. 初始化上下文：将用户任务存入messages数组，作为初始的上下文信息。
2. 模型决策：调用大模型，传入当前上下文（messages）和工具列表（tools），让模型判断下一步动作——是直接返回回答，还是需要调用工具。
3. 记录模型响应：将模型的响应（无论是回答还是工具调用指令）存入messages，更新上下文。
4. 工具执行判断：如果模型没有返回工具调用指令（!response.toolCall），说明任务已完成，直接返回模型的最终回答；如果有工具调用指令，则执行对应的工具。
5. 更新上下文并循环：将工具执行的结果（observation）存入messages，更新上下文，进入下一轮循环，直到完成任务或达到8步的步数限制。

很多文章会把Agent的逻辑讲得很神秘，但把这段核心代码摆出来就会发现，它本质上就是一个“调模型→判断是否调用工具→执行工具→回写上下文→继续循环”的简单流程。

当然，生产级Agent的实现会比这复杂得多，比如会添加流式响应、事件系统、工具的串行/并行调度、工具执行前后的钩子（hook）等机制，但核心主干从未改变。我们之前分析过《OpenClaw 背后的秘密武器：极简智能体框架 Pi 》，其核心文件agent-loop.ts虽然有639行代码，但主干仍然是类似的循环结构——外层用while(true)循环，每一轮同样是调用模型、检查工具调用、执行工具、回写上下文，区别只是增加了生产级所需的各类辅助机制，骨架始终没有变化。

但问题也随之而来：这个最小Loop能跑起来，不代表它能在实际工程中使用。它没有处理权限控制，没有限制危险命令，没有裁剪工具输出的冗余信息，没有设计合理的记忆策略，也没有明确的任务完成验证标准。也就是说，30分钟能轻松跑通Agent的最小闭环，但接下来所有的工程问题，本质上都是在回答同一句话：这个Loop放进真实世界以后，怎么才能不乱跑、不翻车。

4、Agent工具的核心设计逻辑

在最小版本的实现中，我们很容易将工具写成一个简单的函数列表，比如：

const tools = [
listFiles,
readFile,
runCommand,
];

但这样的写法，只能说明程序中存在这三个函数，并不能满足Agent的实际需求。对Agent而言，工具不仅仅是“可调用的函数”，更需要让模型清楚地知道：每个工具能做什么、需要哪些参数、什么时候该用、失败时会返回什么；同时，程序还需要判断：工具的参数是否可信、文件路径是否超出工作区范围、命令是否安全、工具输出的内容是否需要裁剪等。

因此，实际工程中，工具的定义更接近下面这种结构化的形式，这也是Function Calling或Tools API要解决的核心问题——让模型用结构化的方式，清晰表达“我要调用哪个工具、带什么参数”：

const tools = [{
name : "read_file",
description: "Read a text file inside the current workspace.",
inputSchema: {
type: "object",
properties: {
path: { type: "string" },
},
required : ["path"],
},
}];

目前，OpenAI、Anthropic、Google、DeepSeek等各家大模型的工具接口细节略有不同，但核心方向一致：工具名、工具描述、参数schema、调用结果等，都尽量采用结构化设计，让模型能精准理解和调用工具。

这里需要特别补充一个重要的边界认知：Function Calling仅解决“怎么表达工具调用”的问题，它不会替我们解决以下工程化问题，这些都需要额外设计实现：

• path参数是否越过工作区边界，导致访问无关文件；

• run\_command执行的命令是否危险（如删除文件、泄露环境变量）；

• 工具返回2MB甚至更大的日志时，是否需要裁剪，避免占用过多Token或污染上下文；

• 命令执行失败后，是选择重试、降级执行、询问用户，还是直接停止任务；

• 模型连续调用工具8次仍未完成任务时，系统是否需要主动切断循环，避免无限执行。

Pi框架的coding tools设计，就很好地体现了“工具可控”的原则：它默认只提供Read、Bash、Edit、Write四个核心工具，初次看到时可能会觉得工具太少，但仔细思考就会发现，写软件的核心主路径其实很明确：读代码→改代码→跑一下看结果，这四个工具刚好覆盖了这条主路径。工具数量越少，系统提示词就越简洁，模型误用工具的概率就越低，出现问题后也更容易追溯和排查。当需要扩展能力时，Pi更倾向于将扩展能力放在系统侧，而不是一开始就把工具列表铺得很大。

说到底，Agent的工具调用，本质不是把函数暴露给模型，而是把真实世界切成一组可控的入口。入口越少，每个入口的边界就越容易守住，Agent的运行也就越安全、越可控。

这一点，我们回头看Claude Code就能更好地理解：Claude Code不仅仅是“模型+ Bash”的组合，它还围绕Bash、Read、Edit、WebFetch等工具，做了完善的权限控制、动作确认、环境隔离和输出处理。Anthropic的Bash tool文档中也明确提醒：Bash是直接访问系统的能力，使用时必须做好环境隔离、命令过滤、资源限制和日志记录。我们的手搓版用一个run\_command就能演示工具调用的概念，但一旦要做成可落地的工具，这些边界控制就必须全部补上。

5、工具调用的进化：从提示词解析到Function Calling

很多教程讲解Agent时，会直接从Function Calling开始，仿佛它是天生就存在的能力，但实际上，“让模型调用工具”的实现，经历了一个从原始到成熟的进化过程，其中有一个很容易被跳过的关键阶段——提示词解析。

第一代“让模型调工具”的做法非常原始：在系统提示词中，把工具名、参数格式、返回约定等全部写清楚，然后要求模型以JSON格式输出调用意图，再由程序手动解析JSON、将调用指令分发到对应的函数。这套方案确实能跑通，很多早期的Agent Demo都是这么实现的，但写过这类代码的开发者都知道，它存在几个非常现实的痛点：

• 提示词维护成本高：工具数量越多，提示词就越长，后续修改、新增工具时，需要同步修改提示词，很容易出错；

• 格式稳定性差：模型输出的格式全靠提示词约束，偶尔会出现格式跑偏的情况，导致程序解析失败；

• 解析逻辑复杂：需要手动编写JSON解析逻辑，处理各种边界情况（如格式错误、参数缺失等），增加了开发成本。

2022年，ReAct论文提出了一个关键思路，彻底改变了Agent工具调用的范式：模型不应该只在文本中猜测下一步动作，它可以通过主动执行动作，向环境获取新的观察结果，形成“Thought（思考）→ Action（动作）→ Observation（观察）”的闭环。这个范式影响了后续所有Agent框架的设计方向，让Agent的工具调用从“被动解析”走向“主动交互”。

2023年6月13日，OpenAI将Function Calling纳入Chat Completions API，标志着工具调用进入主流开发接口：工具名、描述、参数schema等由API层统一承载，模型会用结构化的方式输出工具调用意图（包括工具名和参数），开发者无需再手动编写JSON解析逻辑，大幅降低了开发成本。随后，Anthropic、Google、DeepSeek等厂商纷纷跟进，虽然接口细节略有差异，但核心方向完全一致——用结构化方式规范工具调用。

回头看这个进化过程，我们能清晰地感受到Agent工程的核心逻辑：Agent的开发很少能一次设计到位，更常见的是“先跑通，再优化”——发现提示词解析不稳，就补上Function Calling；发现工具调用没有边界，就补上schema校验和权限控制；发现模型会无限循环调用工具，就补上步数限制和超时机制。每一层优化，都是从“能跑”到“跑稳”的跨越，每一个边界的补充，都是为了解决实际工程中的痛点。

6、Agent的运行控制：Harness的核心价值

在我们手搓的最小Loop中，特意加入了step < 8的步数限制——这是一个很简单、甚至有些“粗糙”的限制，但却非常实用。如果没有这类限制，Agent很容易出现各类失控问题，具体包括：

• 无限循环：一直调用工具，无法判断任务是否完成，陷入死循环；

• 错误掩盖：工具执行失败后，模型仍继续往下执行，假装执行成功，导致后续动作全部出错；

• 上下文污染：读取过多无关文件，导致上下文信息冗余、混乱，影响模型决策；

• 提前终止：还未完成任务、未验证结果，就提前返回“任务完成”；

• 结论误判：将工具执行的中间日志，当成最终的任务结论返回给用户。

这些问题，虽然和模型本身的能力有一定关系，但更多是发生在Agent运行过程中的工程化问题，需要通过专门的运行控制系统来解决——这就是Harness的核心价值。

很多人会误以为Harness是给Agent套的一层“装饰壳”，其实不然：Harness是将最小Loop放进真实工程环境后，必须补上的运行控制系统，它的核心作用是约束Loop的运行，让Agent从“能跑”变成“能稳定、安全地跑”。一个最小化的Harness，至少需要管理以下9个核心内容：

• 最大循环轮数：避免无限循环，比如我们手搓版中设置的8步限制；

• 最大工具调用次数：防止模型频繁调用工具，浪费资源；

• 单次工具超时：避免工具执行时间过长，导致整个Agent卡住；

• Token和成本预算：控制模型调用和工具执行的成本，避免超支；

• 工具输出裁剪：对工具返回的大量日志、冗余信息进行裁剪，避免污染上下文、占用过多Token；

• 错误分类和恢复：对工具执行失败、模型决策错误等情况进行分类，制定对应的重试、降级或终止策略；

• 关键动作确认：对高风险工具调用（如写文件、删除文件），需要经过人工确认后再执行；

• 日志和回放：记录Agent的每一步动作、模型响应、工具执行结果，方便后续排查问题、审计追溯；

• 任务完成标准：明确什么情况下才算任务真正完成，避免模型提前终止或误判。

Pi框架的Harness实现，就很有参考价值。它在agent-loop.ts中提供了两个核心钩子：beforeToolCall和afterToolCall。其中，beforeToolCall在工具执行前拦截，可用于校验工具参数、检查权限、直接拦截不安全的工具调用；afterToolCall在工具执行后介入，可用于修改工具返回内容、标记错误、做输出裁剪。这两个钩子虽然简单，却把“工具执行前后的控制权”从模型手里拿了回来，交给了工程侧，让开发者能更好地约束Agent的运行。

如果我们把Claude Code、Codex、OpenClaw这几个成熟框架放到这个逻辑中看，就能更清晰地理解它们的差异与共性：三者的核心都是最小Loop，但各自补上的边界不同，适合的场景也不同。Claude Code更偏向Coding Agent，重点完善了仓库上下文、文件工具、Bash、Todo、Subagent、Compact压缩、权限和验证等边界；Pi框架走的是克制路线，默认只保留4个核心工具，搭配只读工具和扩展系统，让上下文更干净、更易审计；OpenClaw则更偏向长期通用Agent，重点完善了消息入口、会话管理、工作区、记忆、插件、网关、安全边界等，其底层使用的正是Pi的引擎。

7、Agent记忆系统：三层设计逻辑

在我们的手搓版Agent中，记忆的实现非常简单：就是将用户消息、模型响应、工具观察结果依次存入messages数组，形成上下文记忆，代码如下：

messages.push(userMessage);
messages.push(assistantMessage);
messages.push(toolObservation);

这种方式，对于短任务来说完全够用，但只要任务稍微复杂、执行步骤增多，就会遇到几个非常现实的问题：

• 上下文冗余：工具输出的内容越来越多，导致messages数组过大，占用过多Token；

• 干扰严重：旧的错误路径、无关的中间结果一直留在上下文里，影响模型的决策准确性；

• 成本上升：对话越长，模型调用的Token成本越高；

• 记忆丢失：会话一旦重启，所有的上下文记忆都会丢失，无法复用之前的信息；

• 效率低下：模型需要在大量冗余信息中筛选有用内容，降低决策效率。

因此，我们不能把Agent的记忆简单理解为“保存所有聊天记录”，更科学的做法是将记忆拆分为三层，每一层都有明确的存储内容和存储载体，核心目标是“在合适的时机，召回对当前任务有用的信息”，具体分层如下：

层次	保存什么	适合放哪里
当前上下文	当前任务需要的消息、工具结果、文件片段等临时信息，仅用于当前任务的循环决策	messages/ context window（模型上下文窗口）
持久事实	项目约定、用户偏好、长期背景信息等，可跨任务复用的固定信息	Markdown文件 / 数据库（DB） / 用户profile
过程经验	某类任务的执行方法、踩坑路径、工作流程等，可沉淀复用的经验性信息	Skills（技能库） / playbooks（操作手册） / procedures（流程文档）

OpenClaw、Hermes、Clawdbot等系统的记忆设计，都遵循了这个分层逻辑，只是侧重点不同：

OpenClaw和Clawdbot走的是工程化路线，将记忆存入工作区文件，让记忆具备可读、可改、可审计、可迁移的特点。比如用memory/YYYY-MM-DD.md记录每日的任务流水，用MEMORY.md保存长期的持久事实；在检索记忆时，不会把整个记忆文件塞给模型，而是返回有用的片段、文件路径和行号，避免上下文污染。

Hermes则更注重过程经验的沉淀，它将事实和用户偏好存入基础记忆，而将各类任务的执行经验沉淀为Skill（技能），重点解决“这类事情以后怎么做”的问题，提升Agent的复用能力和执行效率。

这两条路线，本质上都指向同一个核心：记忆系统的目标不是让Agent记住所有内容，而是精准召回有用信息。对于我们的手搓版Agent，如果要添加记忆功能，建议先从最小版本入手，用简单、可理解的方式实现，代码示例如下：

const memory = {
projectRules: readMarkdown("AGENTS.md"),
recentSummary: readMarkdown("memory/session-summary.md"),
};
const messages = [
{ role: "system", content: memory.projectRules },
{ role: "system", content: memory.recentSummary },
{ role: "user", content: task },
];

先用Markdown文件存储持久事实和近期摘要，优先保证记忆的可读性和可维护性，让开发者能清晰看到Agent的记忆内容。等后续内容量增加、召回需求提升、跨项目复用成为刚需时，再逐步引入向量库、全文检索、信息重排和自动整理等更复杂的技术。

很多系统的记忆设计之所以出问题，不是因为没有记忆功能，而是太早把记忆做成了黑盒——一开始就引入向量库、自动摘要等复杂机制，导致记忆的流向不可追溯、问题难以排查。Agent工程的很多环节都遵循“先跑通最小版本，再按痛点优化”的节奏，记忆系统也不例外：先用简单的方式跑通，碰到瓶颈再逐步加层，每一层优化都要有明确的痛点驱动。

8、Agent权限分级策略

记忆系统解决了“Agent知道什么”的问题，而权限系统则解决了更敏感的“Agent能做什么”的问题。在我们的手搓版Agent中，最危险的工具就是run\_command——一旦将Bash等系统命令交给模型，Agent的能力会瞬间提升，它可以列目录、读文件、跑测试、调用CLI工具，但同时也可能误删文件、泄露环境变量、访问外部网络、执行长时间运行的命令，引发安全风险和系统故障。

因此，我们不能把“给模型开放Bash权限”理解为一种“酷炫的能力”，它更像一把锋利的刀——好用，但必须有刀鞘约束，这个刀鞘就是权限系统。

Claude Code的权限系统，就为我们提供了很好的参考：它将工具调用分为“允许直接执行”“需要询问用户”“禁止执行”三类，平衡了安全性和易用性。Anthropic在后续推出Claude Code auto mode时，也提到了一个很实际的矛盾：每次写文件、跑命令都询问用户，虽然安全，但会带来“审批疲劳”，影响使用体验；完全不询问用户，又会放大安全风险。

他们的解决方案，不是简单地“取消询问”，而是用分类器在工具执行前，自动识别动作的风险等级——低风险动作直接放行，高风险动作则拦截并询问用户。根据Anthropic的工程文章披露，在真实的overeager actions数据集上，这套完整的权限 pipeline 仍有17%的假阴性率（即高风险动作被误判为低风险而放行）。这个数字很有价值，它告诉我们：自动化权限系统可以减少人工干预，但不能完全拿掉高风险动作的人类确认环节，安全边界必须守住。

OpenClaw的实践也印证了这一点：作为通用Agent，一旦接入聊天入口、插件、工作区和本地工具，网关和权限边界就不再是“安全附录”，而是Agent运行主路径的一部分——没有完善的权限控制，Agent就无法长期、安全地运行在真实工程环境中。

对于我们的手搓版Agent，建议将权限分为四档，每一档都有明确的适用场景和默认策略，既保证可控性，又兼顾易用性，具体分级如下：

权限层	例子	默认策略
只读	list\_files、read\_file，仅用于查看文件和目录，不修改任何内容	可直接执行，无需人工确认
安全执行	npm test、pytest、go test等测试命令，仅用于验证代码正确性，无安全风险	白名单机制，仅允许执行白名单内的命令
写操作	write\_file、apply\_patch，用于修改文件内容，可能影响代码逻辑	需要人工确认，确认后才能执行
高风险动作	删除文件、访问外部网络、读取凭证信息、操作系统目录等，可能导致系统故障或信息泄露	默认禁止，如需执行，需手动开启权限并确认

这份权限分级表看似简单，却决定了Agent的本质——它是一个可控的工程工具，还是一个可能引发事故的“隐患”。权限控制不是越多越好，而是要精准分级，在安全和易用性之间找到平衡，这也是Agent能长期稳定运行的核心底线。

9、Agent的任务验证体系

权限系统管住了Agent“能做什么”，但还有一个关键问题：当Agent说“任务完成了”，我们怎么知道它真的完成了？

Agent最容易让人误判的地方，就是它很擅长用自信的语气输出“任务完成”，但在工程实践中，“完成”不是一句口号，而是需要有明确的证据支撑。如果我们的手搓版Agent，最后只返回一句任务完成。，这样的回答没有任何工程价值——我们无法确认它是否真的完成了任务，也无法排查可能存在的问题。

一个有价值的Agent，在声称“任务完成”时，至少要能回答以下6个问题：

• 为了完成任务，读取了哪些文件？

• 调用了哪些工具，每个工具的执行结果是什么？

• 对代码或文件做了哪些修改，修改的依据是什么？

• 运行了哪些测试，测试结果是否通过？

• 哪些检查（如类型检查、lint格式化）已经通过，哪些还未通过？

• 还有哪些潜在风险没有处理，后续需要做什么？

对于Coding Agent而言，最小化的任务验证体系，通常包括以下6个核心环节，缺一不可：

• 相关测试通过：执行对应的单元测试、集成测试，确保修改后的代码能正常运行；

• 类型检查通过：对于TypeScript、Go等强类型语言，确保类型定义正确，无类型错误；

• lint或格式化通过：确保代码风格统一，无语法错误、格式问题；

• diff能对应用户任务：代码修改的内容（diff），必须与用户交给的任务需求一致，无无关修改；

• 失败时有错误摘要和下一步建议：如果任务执行失败，需清晰输出错误原因、错误位置，并给出可落地的下一步建议；

• 高风险改动有人确认：对于写文件、删除文件等高风险改动，必须经过人工确认后，才能视为“完成”。

这也是我们在观察Claude Code、Codex、OpenClaw等成熟系统时，最需要关注的部分。随着大模型能力的不断提升，“能写出一段代码”已经不再稀奇，更稀缺的能力是：能把上下文、工具、权限、测试、日志和错误恢复，整合为一个完整的闭环，真正具备工程可用性。

没有验证体系的Agent，本质上只是一个“很会解释”的聊天机器人——它能告诉你“该怎么做”，但无法证明“已经做好了”；而有了验证体系，Agent才真正接近一个能与开发者协作的工程工具——它能落地执行，能验证结果，能排查问题，能承担实际的开发任务。

这也是我自己踩过的一个坑：传统CI/CD系统跑失败了，查看日志就能明确知道哪行代码报错、问题出在哪里；但Agent跑“成功”了，反而需要更加警惕——因为模型太擅长用自信的语气说“搞定了”，但它口中的“搞定”，和工程意义上的“搞定”，往往不是一回事。验证体系，就是连接“模型自信”和“工程可用”的关键桥梁。

10、Claude Code的核心逻辑：最小循环的工程化增厚

看到这里，再回头看Claude Code这样的成熟产品，就会觉得豁然开朗。之前拆解Pi框架源码时，就有一个深刻的感受：它的agent-loop.ts虽然有600多行生产级代码，但核心主干和我们手搓的最小Loop几乎一致；Claude Code也是如此，它的核心逻辑没有什么神秘的新机制，只是把一个朴素的Loop，放进了真实的软件工程环境中，补上了所有必要的边界。

我们手搓的最小Loop，逻辑非常简单：Model -> Tool -> Observation -> Loop（模型→工具→观察→循环）。

而Claude Code的逻辑，更像是在这个最小Loop的基础上，层层叠加了工程化能力，完整链路如下：

Model → Repo Context（仓库上下文） → Tool System（工具系统） → Permission（权限控制） → Bash / Read / Edit（工具执行） → Todo / Subagent（任务拆分与分发） → Compact / Memory（上下文压缩与记忆） → Validation（验证） → Loop（循环）

它没有把Agent Loop变成玄学，只是把一个能跑的最小闭环，改造为能适应真实工程场景的系统。这也是为什么同一个大模型，在聊天框里和在Claude Code里的使用体感完全不同：

在聊天框里，模型的核心作用是“生成文本”——你问它“帮我改个bug”，它只能告诉你“你可以试试这样改”，无法实际操作；而在Claude Code里，模型进入了一个完整的工作台——它能查看仓库结构，能读取具体的代码文件，能执行测试命令，能记录待办事项（Todo），能把复杂任务拆分给subagent（子Agent），能在上下文冗余时进行Compact压缩，还能在权限系统的约束下安全行动。它不是在“说”怎么改bug，而是真的在“做”——这就是Harness（运行控制系统）的价值，也是Loop外面那些边界的价值。

把前面所有的内容，再次浓缩为一句话：30分钟手搓Agent，我们看到的是Agent的核心Loop；而Pi、Claude Code、OpenClaw这些成熟框架，补上的是这个Loop在真实世界里工作所需要的所有边界——工具边界、上下文边界、记忆边界、权限边界、验证边界。

11、写在最后：Agent工程的核心是“跑稳”

手搓一个最小Agent，其实很容易让人兴奋——几十行代码，就能让模型读取任务、调用工具、获取结果、循环执行，第一次看到它“自己动起来”时，那种成就感非常强烈。但我自己写下来最大的收获，其实不是“跑通了”这个结果，而是“跑通”之后的思考：最小循环只是Agent的起点，让它跑起来不难，难的是让它跑得住、跑得稳。

工具边界、上下文边界、记忆边界、权限边界、验证边界，这五层边界，每一层都是从“Demo能用”到“日常能靠”的距离，每一层都需要大量的工程化细节来支撑。这些细节，没有模型本身那么显眼，没有“自主智能”那么吸引眼球，大多是校验参数、裁剪输出、管理权限、运行测试、记录日志、处理错误恢复这些“细活”，但正是这些细活，决定了Agent能不能真正进入日常的工程链路，能不能成为开发者可以信赖的协作工具。

我一直有个不太成熟的看法：未来半年到一年，大模型本身的能力会逐渐趋同——各家模型的推理能力、理解能力、工具调用能力，差距会越来越小；而更容易拉开差距的，会发生在模型外面，也就是Harness这一层。谁的工具系统更可控，谁的记忆策略更精准，谁的权限和验证更可靠，谁的Agent就更能长期稳定地干活，就更能从“聊天机器人”升级为“工程协作工具”。

这也是我最近持续研究和撰写Harness系列内容的原因——它没有那么多酷炫的概念，却承载着Agent工程化的核心价值。这篇文章，算是一个起点，后续我会继续拆解Claude Code的具体模块、OpenClaw的系统边界，以及Harness在多Agent场景下的新挑战。

如果你也在开发Agent，欢迎留言聊聊你踩过的坑——很多好的工程经验，都是从坑里长出来的；很多边界的设计，都是为了解决那些“跑不通、跑不稳”的实际问题。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？