DeepSeek Harness实战：从零搭建AI Agent完整指南

DeepSeek Harness 这个词，我最早是在折腾 Agent 项目时反复看到的。那时候我手头堆了一大堆“大模型怎么接、上下文怎么管、工具怎么调”的零碎经验，但一直没找到一个能把这些事整合起来的直接工作流。直到我把 DeepSeek Harness 装起来，从写第一个指令文件到跑通一个能自己读文件、自己拆任务的 Agent，整个过程比我想象中顺畅很多。这篇就当作一份实操记录，从一个新手视角，把“从零到一搭建 AI Agent”这条路尽量完整地走一遍。

这篇文章适合谁？你如果只是调过 API、和大模型聊过天，但还没真正做过一个“能干活”的 Agent；或者你已经听说过 LangGraph、MCP、工具调用这些词，但不知道怎么落到一个具体工具里，那这篇正好合适。我尽量把每一步的原理和操作都讲清楚，不预设你已经熟悉 Agent 工程。

1. 初识 DeepSeek Harness：它到底解决了什么问题

很多人的第一个疑问是：直接调 DeepSeek 的 API 不就行了吗，为什么还要多套一层 Harness？这个问题问得很关键，理解它，你才算真正理解 Agent 工具的价值。

1.1 Harness 是什么：给大模型套上“缰绳”

Harness 在英文里有“马具、挽具”的含义，引申过来就是“控制装置”。在 AI 工程里，Harness 就是套在模型外面的那层工作框架。裸的模型接口只做一件事：你给它一段文本，它给你续写一段文本。而 Harness 做的事情，是把这只看似无所不知、但没有手脚的“大脑”，绑在一个完整的工作流程上——给它分配任务、给它可以操作的工具、让它在一个循环里反复尝试，直到任务完成。

DeepSeek Harness 就是这样一套围绕 DeepSeek 系列模型（当然，很多类似框架也支持接其他兼容模型）搭建的 Agent 工作台。它不是一个简单的聊天前端，而是一个能承载“模型 + 工具 + 流程 + 记忆”的完整运行环境。

我用一个比较生活化的类比：你雇了一个非常聪明的远程助理，但这个助理没有电脑、没有电话、没有文件系统。你每次都得把资料复印好递给他，他分析完再把结论口述给你。这太累了。Harness 相当于给这个助理配齐了电脑、文件柜和各种办公软件，还定了一套工作汇报制度——他终于可以独立干活了。

1.2 对话模型和 Agent 的差别：从“顾问”到“执行团队”

只调 API 的对话式用法，本质上是在和“顾问”聊天。你问它“如何写一份市场分析报告”，它能给你列出详细的框架和步骤，但它不会真的去查数据、不会生成文件、不会自我检查。顾问负责出主意，活还是得你干。

Agent 则更像一个“执行团队”。它的工作方式不是“你问我答”，而是“你布置任务，它拆解任务、调用工具、验证结果、交付成品”。同样是写市场分析报告，Agent 能做的是：打开你指定目录下的销售数据文件，提取核心指标，调用网络接口补一些公开信息，按照你给定的报告模板生成 Markdown 文档，保存到指定路径，最后告诉你“报告已完成，需要调整随时说”。

这个转变之所以难，是因为它涉及的不只是“模型更聪明一点”，而是一整套工程组件的协作：

• 上下文怎么管理：任务复杂时，模型需要看很多资料，但一次能输入的文本有上限，Harness 要负责压缩、摘要、分段处理。
• 工具怎么调用：模型“决定”要读取某个文件，Harness 要负责把模型的意图解析成真实的文件读取操作，再把读取结果交还给模型。
• 流程怎么控制：Agent 不是问一句答一句，它要在一个循环里不断“思考 → 行动 → 观察结果 → 再思考”，直到它认为任务完成或主动向你求助。

DeepSeek Harness 的核心价值，就是把这套东西做成开箱即用的默认流程，让普通开发者不需要从零搭建一个 Agent 编排引擎。

1.3 一个 Harness 框架里通常有什么

我在实际使用中，发现这类框架不管界面怎么变，核心大都是这几块：

• 模型连接层：负责对接大模型 API，处理鉴权、请求重试、流式输出。
• 指令集（Skill / Instruction）：这是 Agent 的“工作手册”，定义它在特定任务里的角色、流程和输出规范。保存成一个文件，随时复用。
• 工具层：Agent 能操作的外部能力，比如读取本地文件、执行命令行、发起 HTTP 请求。工具越多，它能干的活就越多。
• 会话与记忆管理：保存多轮对话状态，处理长任务的上下文压缩。
• 执行引擎：把“思考 → 调用工具 → 收集结果”跑成一个可控的循环。

理解了这五个模块，后面很多操作你一看就明白是在配置什么了。

2. 安装与环境配置：从下载到跑通命令行

安装这类工具，最怕的不是复杂，而是各种前置条件没满足导致的连锁报错。我这边把安装过程拆成几步，尽量把容易踩的坑提前指出来。

2.1 环境准备：不挑机器，但有几个底线

DeepSeek Harness 的定位是“框架 + 客户端”，实际的模型推理发生在云端 API，本地只跑任务编排和工具执行逻辑，所以它对硬件的要求比本地跑大模型低很多。

• 操作系统：Windows 10/11、Ubuntu 20.04 及以上、macOS 都可以。我在 Windows 和 Ubuntu 上都跑过。
• Python 版本：这类工具大多基于 Python，建议装 Python 3.10 或更高版本。安装前在终端里执行python --version确认。
• 内存：8GB 以上比较稳妥。上下文处理、日志记录、多 Agent 并发都会吃内存，16GB 会更从容。
• 显卡：不是必须的。本地不跑推理，集成显卡都没问题。当然，如果你要接本地小模型，那是另一套玩法。
• API Key：需要有一个 DeepSeek 开放平台的 API Key，用于连接模型服务。

2.2 安装三步走：选渠道、配 Key、验证版本

第一步：安装框架本体。根据你下载的版本不同，有两种常见方式：

• 命令行版，一般通过包管理器安装，我当时的安装命令类似：

pip install deepseek-harness

• 桌面版（Desktop），官网通常提供安装包，Windows 下是 exe 安装向导，Ubuntu 下是 deb 包或 AppImage。

如果你有安装目录的偏好，比如想把程序装到 D 盘而不是 C 盘，用安装包时在向导界面手动改路径就行。命令行版的话，我建议把 Python 环境本身管理好，虚拟环境装哪里由你决定。

第二步：配置 API Key。申请好 DeepSeek 开放平台的 Key 之后，有两种配置方式：

方式一，环境变量，这也是我觉得最干净的方式：

# Windows PowerShell setx DEEPSEEK_API_KEY "sk-你的key" # Ubuntu / macOS export DEEPSEEK_API_KEY="sk-你的key"

注意：setx设置的环境变量只在新的终端窗口生效，设置完后务必重新打开终端。我自己就在这里卡过一次，改完以为没生效，其实是不需要重装，开新窗口就好。

方式二，配置文件。首次运行harness时，通常会有一个配置向导，按提示填入 Key、选择默认模型即可；也可以手动编辑配置文件，一般位于用户目录下的.deepseek-harness/config.yaml之类的位置。

第三步：验证安装。在终端执行：

harness --version

如果看到版本号输出，说明框架本体装好了。接着可以执行一个快速连通性测试：

harness doctor

有的版本提供这类自检命令，会检查 API Key 是否有效、网络是否通、核心配置是否缺失。这一步能省下很多排查时间。

2.3 安装后常见的两个问题

我遇到的第一个问题是harness命令找不到。明明 pip 装成功了，终端却提示 command not found。这通常是 Python 的 Scripts 目录没有被加入 PATH。Windows 上可以检查Python安装目录\Scripts是否在系统环境变量里，或者在命令行用一次性方式运行：

python -m deepseek_harness --version

第二个问题是路径带中文或空格导致的奇怪报错。有一次我把项目放在D:\学习资料\agent项目下，启动后读取配置一直异常，后来改成纯英文路径就正常了。这类工具内部要拼接各种脚本路径，中文路径容易在跨模块调用时出问题。建议安装目录和工程目录都用英文命名。

2.4 DeepSeek Harness 和 Codex Harness 怎么选

很多人在搜索时会在 DeepSeek Harness 和 Codex Harness 之间纠结。我自己的理解是，它们属于同一类“Harness 工作台”思路，但侧重点不同。

Codex Harness 更偏向代码生成和仓库级任务，适合那种“打开一个代码仓库，让模型理解代码结构、改 bug、写测试”的场景。DeepSeek Harness 则更偏向通用任务执行，尤其是中文场景的文档处理、信息整理、多步骤任务编排，同时对 DeepSeek 系列模型做了更深入的适配。

如果你主力模型就是 DeepSeek，日常主要做文本处理、任务编排、文件操作这类工作，那 DeepSeek Harness 的体感会更顺滑。如果你主力场景是“让 AI 在大型代码库里干活”，可以再评估 Codex Harness。两者不冲突，按场景选型就好。

3. 第一个 Agent 实战：做一个“日报整理助手”

装好框架只是第一步。这一节我们直接动手，从零写一个能用的 Agent。目标很小但功能完整：把零散的今日工作事项，整理成一份结构化的日报。

3.1 先理解三个词：模型、指令集、工具

动手之前，必须先厘清 DeepSeek Harness 里三个出现频率极高的概念：

• 模型（Model）：Agent 的“大脑”，负责理解任务、推理步骤、生成文本。你可以在配置里切换不同型号的 DeepSeek 模型。
• 指令集（Skill / Instruction）：给大脑的“工作手册”。它是一段精心编写的提示词，定义了 Agent 在特定任务中的身份、工作流程、输出规范。保存成单独的 Skill 文件后，可以在不同会话中复用。
• 工具（Tools）：Agent 的“手”。包括读取文件、执行命令、发起网络请求等能力。要让 Agent 真正“做事”，至少得配置一个工具让它实操。

做个简单类比：模型是员工，指令集是员工手册，工具是员工手上的办公设备。三者缺一个，Agent 都算不上完整。

3.2 实操：创建指令文件并跑通流程

第一步：创建一个 Skill 文件。在 Harness 的 skills 目录下（通常是用户目录的.deepseek-harness/skills/），新建一个daily_report.md文件，内容类似：

--- name: daily_report description: 将零散工作事项整理为结构化日报 --- 你是一名经验丰富的项目助理，你的工作是将用户提供的零散工作事项整理成一份结构化日报。 当用户输入原始事项时，按以下格式输出： ## 今日完成 - 按优先级列出已完成事项 ## 进行中 - 列出进行中事项及当前进度 ## 风险与待协调 - 列出需要他人配合或资源协调的事项 ## 明日计划 - 列出明日优先要做的事项 规则： 1. 不要编造事项，只整理用户实际提供的内容；信息不足时明确标注“信息缺失”。 2. 同一个事项如果与多个板块相关，放在最合适的一个板块，不要重复罗列。 3. 每条事项尽量用一句完整的话描述，包含对象和结果。 4. 最终结果用 Markdown 输出。

第二步：启动 Harness 并加载 Skill。在终端执行：

harness --skill daily_report

有的版本是进入交互界面后再通过命令加载 Skill，具体看你版本的启动参数。启动后，你进入一个命令行对话界面，可以像聊天一样和 Agent 对话。

第三步：用一段原始素材做测试。我给 Agent 输入：

今天上午搞定了登录模块的 bug，下午开了一个新需求评审会，客户那边催进度催得比较紧，明天要准备一个演示版本，对了还有数据库连接池的配置没有调完。

Agent 会按照指令文件的格式，输出类似这样的结构化日报：

## 今日完成 - 修复登录模块 bug，问题已解决并完成验证。 ## 进行中 - 新需求评审会已开，需求细节待同步研发团队。 - 数据库连接池配置尚未调完，属于进行中事项。 ## 风险与待协调 - 客户对项目进度催促较紧，建议本周内安排一次进度同步会。 ## 明日计划 - 准备演示版本。 - 完成数据库连接池配置调优。

到这里，你的第一个 Agent 实际上已经跑通了。它做的事情很简单，但你注意看，它做了分类、去重、信息补全判断，这些都是指令文件里设计好的行为。工具的意义不是变魔法，而是把模型的行为约束到稳定的轨道上。

3.3 关键一步：从“单轮模板”到“自主规划”

刚才的例子还偏“模板填充”，很多人会觉得这不够 Agent。确实，真正有价值的 Agent 要能“自主规划子任务”。怎么让它迈出这一步？其实非常简单：在指令文件的规则里加一条。

我在daily_report的规则里加了一条：

5. 如果任务步骤超过三步，先向用户输出简要执行计划，说明你将按什么顺序处理，每完成一步，用一行文字汇报进度。

加了这条之后，当你给它一个更复杂的任务，比如“分析本周的 todos 并整理出周报和风险清单”，你会发现它不再机械地套模板，而是先给你输出一个计划：

我打算按以下步骤处理：

1. 读取你提供的 todos 清单
2. 按完成状态分类，提取关键事项
3. 生成周报正文
4. 补充风险清单

现在开始第一步：读取 todos 清单……

这个细节，是“套壳聊天”和“Agent”之间最明显的一道分水岭。自主规划的本质不是模型突然变聪明了，而是你在指令层面给了它“先计划再执行”的权限和流程约束。

3.4 首次实战的注意事项

第一次跑通时，我建议你把实验范围控制得很小：一个指令文件、一个简单场景、一段不超过几百字的输入。不要一上来就让它分析整个项目文件夹，那会让变量太多，出了问题你都不知道是模型的问题、指令的问题还是工具的问题。

还有一个容易忽略的细节：模型输出带格式但是乱。比如明明要求按## 今日完成输出，它却擅自在前面加了一段“好的，我已经整理好了”。这种问题可以在指令里明确加一句“不要输出与格式无关的客套话，直接输出日报正文”。语言模型实在很容易为了礼貌而破坏格式，指令里禁止客套，比表达客观更有效。

4. 深入理解 Agent 的设计原理：为什么它看起来会“思考”

很多新手用完 Harness 后最大的困惑是：咦，它怎么知道要先规划、再执行？它怎么知道该调用哪个工具？这里拆开讲清楚，其实核心机制并不玄乎。

4.1 ReAct 循环：Agent 的思考工作流

Agent 能自主推进，绝大多数靠的是 ReAct 范式，也就是 Reason（推理）和 Act（行动）的交替循环。DeepSeek Harness 把下面这个循环自动化了：

1. 模型接收任务，通常附带当前的上下文信息。
2. 模型进入“思考”阶段：我现在要做什么？需要用什么工具？下一步应该怎么走？
3. 模型输出一个动作指令：可能是“读文件 xxx”，可能是“执行命令 yyy”，也可能是“直接回答用户”。
4. Harness 解析这个动作，实际执行它，把运行结果返回给模型。
5. 模型看到结果，进入下一轮思考，重复第 2 步。
6. 当模型判断任务已经完成，或者需要用户确认时，循环结束。

这个循环翻译成人话，就是“想一下 → 做一步 → 看一眼结果 → 再想”。Harness 做的事情，只不过是把“做一步”和“看一眼结果”这种手工操作自动化了，让模型可以连续工作，直到任务收尾。

4.2 上下文管理：为什么你的 Agent 不会“忘了前面说啥”

大模型的上下文窗口是有限的，而 Agent 干活的时候要消耗大量上下文——指令文件要占、用户输入要占、工具返回的文件内容要占、历史对话也要占。如果完全不管理，很快窗口就被塞满，模型要么开始胡言乱语，要么直接报错。

DeepSeek Harness 在上下文管理上做了几件关键的事：

• 指令裁剪：只把当前任务相关的 Skill 指令加载进上下文，而不是把所有 Skill 都带上。
• 工具结果摘要：读取一个超大文件后，工具不会把全文原封不动塞给模型，而是按需截取、摘要或分块传递。
• 对话压缩：长跑任务中，早期对话被总结成若干条“历史摘要”，释放窗口空间。

这也是为什么你直接调 API 时，稍微多聊几轮就感觉模型“变笨”了，而在 Harness 里它能稳定地连续干活。不是模型变了，而是框架在背后帮你把“记忆”管理得更高效。

4.3 和 LangGraph 这类编排框架的关系

用过 LangChain 或 LangGraph 的朋友可能会有疑问：我直接用 LangGraph 也能搭出 Agent，为什么还需要 Harness？我的理解是，两者定位不同，适合的人也不一样。

LangGraph 更像“积木盒”，它给你图编排、状态管理、节点流控的底层能力，你可以把 Agent 流程做成任何形状。但代价是，你得自己理解图、状态、节点这些概念，自己配置循环和分支，学习成本不低。DeepSeek Harness 则更像“样板间”，它内置了一个经过验证的默认流程，你只需要写指令、配工具、用就好。

更准确地说，Harness 这类工具内部可能也借鉴了类似的编排思想，但不要求你用图论的思维方式去使用它。如果你只想快速做出能用的 Agent，不想深究流程引擎，Harness 更合适；如果你想做高度定制化的复杂流程，那再去学 LangGraph 也不迟。我自己是从 Harness 入门，理解了流程之后再看 LangGraph，反而觉得容易很多。

4.4 指令文件是 Agent 的灵魂

同样的模型、同样的工具，指令文件写得好不好，出来的效果天差地别。就像同一个员工，不同公司的 SOP 和工作手册不同，干活方式和产出质量也完全不同。

好的指令文件通常包含三个层次：

• 角色定义：告诉模型“你是谁”。比如“你是一名经验丰富的项目助理”。这会让模型自动调用相关领域的表达习惯和知识背景。
• 流程描述：告诉模型“先干什么、再干什么、遇到不同情况怎么办”。这一步是 Agent 能自主规划的基础。
• 输出约束：告诉模型“输出什么格式、什么风格、多长”，并对禁止事项做出明确说明。

我做了个对比，你可以感受一下差别：

指令写得越具体，模型的输出就越稳定。新手总以为 Agent“不够聪明”是模型的问题，实际上大部分情况是指令不够清楚。这跟带实习生是一个道理：需求越含糊，产出越随机。

5. 进阶玩法：文件读取、MCP 集成与多 Agent 协作

跑通第一个 Agent 之后，你肯定不满足于让它套模板。这个阶段可以解锁几个关键的进阶能力，让 Agent 真正融入工作流。

5.1 让 Agent 读取本地 Markdown 等文件

很多人最想做的事，就是让 Agent 读自己的一堆笔记、文档，然后基于内容做总结。这在 Harness 里属于“文件工具”能力。

一般的操作方式是：在配置中启用文件系统工具，然后在指令或对话中声明要访问的文件。比如：

/read D:\notes\project_review.md

或者直接在对话里说“读一下 project_review.md 并总结核心观点”。

实操中我总结出三个注意事项：

• 优先用绝对路径，少用相对路径。Agent 的工作目录有时候和你预期的不一致，绝对路径能直接锁定目标。
• 给文件工具设置访问白名单。很多 Harness 工具支持限制访问目录范围，只允许读写指定文件夹，避免 Agent 随手翻遍整个磁盘。
• 大文件要分段读。一个几万字的文件全部塞进上下文，既浪费窗口又容易让模型注意力涣散。我一般先让 Agent “只读前 5000 字并给出片段摘要”，再让它按需深入阅读某个章节。

5.2 MCP 协议：AI 世界的标准 USB-C 接口

MCP（Model Context Protocol）是最近 Agent 生态里绕不开的词。它的核心思路是：把各种外部系统（数据库、飞书文档、天气服务、本地应用等）封装成统一标准的接口，让模型通过同一种协议去调用。你可以把它理解成 AI 世界的 USB-C 接口——以前每个设备都有自己的充电线，现在大家统一了接口。

DeepSeek Harness 支持通过 MCP 协议挂载外部工具。这会大大扩展 Agent 的能力边界。我举个实际例子：假设我想让 Agent 能查询我本地的待办清单，我可以写一个极简的 MCP Server，把自己电脑上的一个 todos.json 文件暴露成一个工具：

from mcp.server import Server from mcp.types import Tool, TextContent import json app = Server("todos-server") @app.list_tools() async def list_tools(): return [ Tool( name="get_today_todos", description="获取今天的待办事项", inputSchema={"type": "object", "properties": {}}, ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "get_today_todos": with open("todos.json", "r", encoding="utf-8") as f: todos = json.load(f) return [TextContent(type="text", text=json.dumps(todos, ensure_ascii=False))] raise ValueError(f"未知工具: {name}")

然后在 Harness 的配置里注册这个 MCP Server，重启后，你就可以在对话里让 Agent “查一下今天的待办”。Agent 会自动决定调用get_today_todos这个工具，而不是靠你手动传文件。

不要被代码吓到。你完全可以在官方文档里找现成的 MCP Server 配置，很多常用系统（数据库、日历、文档平台）都有人已经写好了。理解“MCP = 工具的标准化接口”这一层逻辑就够了。

5.3 多 Agent 协作：一个主理人，多个专属助理

单 Agent 用久了，你会发现它的瓶颈：上下文有限，塞不下太多角色要求；同一个 Agent 又要写代码又要写文案，容易风格混乱；复杂的任务交叉在一起，单线程的 Agent 会顾此失彼。

多 Agent 协作是解决这些问题的自然方式。思路是：一个主 Agent 负责理解用户意图、拆分任务、调度分发；多个子 Agent 各司其职，处理自己领域的事务；最后结果汇总到主 Agent，统一返回给用户。

在 DeepSeek Harness 中，最简单的多 Agent 用法就是把不同 Skill 当作不同“人设”，在对话中显式召唤。比如我建了两个 Skill：

• copilot_dev.md：代码助手，负责写代码、查 bug、做代码 review。
• copilot_writer.md：文档助手，负责写技术文档、做方案整理。

然后在对话中就可以用@copilot_dev 帮我看一下这段代码有什么问题，或者@copilot_writer 把刚才的方案写成一页纸的汇报来分别调度。

多 Agent 不是越多越好。每多一个角色，就多一份上下文开销，也多一份“角色之间互相污染”的风险。我自己在实际项目里，最常用的是“1 个主 Agent + 2 个专业子 Agent”的配置，再多就难维护了。新手建议从“1 主 + 1 副”开始试。

6. 常见问题与排查技巧：我的排错实践

跑到这里，相信不少人的 Agent 已经在干活了。但工具这东西，用得越深，问题越多。我把这段时间遇到的典型问题，连同排查方法整理成一个速查表。

6.1 问题速查表

6.2 一个现场排查实录：会议纪要 Agent 为什么不干活

有一次我做“会议纪要 Agent”，目标是让它读一个会议录音转写的 txt 文件，输出纪要和待办。第一次运行，Agent 什么也没输出，只回复了一句“我无法找到文件内容”。当时我以为是模型不懂怎么用文件工具，后来排查发现根本不是。

我按这个顺序排查：

第一步，看日志。Harness 的执行日志里保留了工具调用记录，我发现 Agent 确实发出了“读取文件”这个动作，但工具返回为空。

第二步，单独测试工具。我在终端里手动执行了文件读取，发现同样返回空——问题不在模型，而在工具。

第三步，检查路径。我发现文件读取的路径参数里，反斜杠被转义处理错了，工具找不到真实文件。

第四步，改写路径格式，重启 Harness，重新让 Agent 读文件，这次成功输出了完整的会议纪要和待办清单。

这个案例教给我的不是具体的路径格式，而是一个排错方法论：先看日志，再单体测试工具，最后才回到整个流程。很多新手一上来就怀疑模型能力，其实九成的问题出在配置和工具层。

6.3 让 Agent 更“听话”的几个指令技巧

用了一段时间，我总结了几个写指令时特别容易见效的习惯：

• 否定指令比肯定指令更重要。与其只说“请输出结构化内容”，不如再加上“不要输出客套话，不要编造数据，不要省略任何指标”。模型对“禁止做什么”的遵循度往往更高。
• 一次只给一个“大任务”，然后要求它自拆子步骤。不要一次性把所有要求堆在同一个自然段里，那样模型容易顾此失彼。
• 用“格式锚点”锚定输出。告诉它“严格按照## 今日完成、## 风险与待协调两个标题输出”，它就不太会自由发挥。
• 要求“先输出计划，再执行”。这是让 Agent 从“被动应答”切换到“主动干活”的最简单开关，一句话就能撬动。

6.4 安全底线：Agent 能干活，也能闯祸

最后一定要说安全。Agent 有了工具调用能力之后，权限边界就非常重要。

• API Key 不要硬编码在共享的指令文件里，用环境变量管理。
• 文件工具的访问范围做最小化配置，只开放 Agent 需要的那几个目录。
• 不要让 Agent 执行来源不明的脚本，尤其是从网上直接复制下来的指令和工具配置。
• 涉及密码、密钥等敏感信息，不要直接粘贴进对话，也不要让 Agent 读取包含密钥的配置文件。

Agent 就像一把好用的电动工具，效率高，但操作前先搞清楚开关在哪、别把手伸进去。这部分意识，越早建立越好。

说实话，从装好 DeepSeek Harness 到跑通第一个像样的 Agent，我最强烈的感受是：这比写传统代码更接近“带新人”。传统代码里，所有逻辑都是你说了算，而 Agent 里你只能通过“指令 + 工具边界”间接影响结果——它会自己规划、自己尝试、有时还会给你惊喜，偶尔也会给你惊吓。这种从“控制逻辑”到“设定边界，让模型自主执行”的转变，是整个 Agent 工程里最有意思的地方。

最后分享两个小建议：第一个 Agent 千万别贪大，一个指令文件、一个工具、一个具体场景，跑通之后再慢慢扩展；平时用“工程日志”把每个指令版本的改动和效果记录下来，你会发现迭代速度比瞎试快得多。希望这篇记录能帮你少踩几个坑。