前言：以前做外贸，电脑里打开的通常是 Google、Excel、WhatsApp、邮箱和各种独立站后台。现在不一样了。除了这些老朋友，越来越多人的电脑里又多了几个新同事：Codex、Claude Code、DeepSeek Harness（DSH）……
这些 AI Agent 的出现，确实改变了很多工作方式。
以前想做一个产品落地页，可能要找设计师、前端工程师，再加一个文案。
现在打开 Agent，告诉它：
“帮我做一个面向欧美市场的 B2B 产品落地页。”
然后，它就能开始研究、写代码、修改文件，甚至自己测试。
听起来是不是很美好？
但当我真正把这些 AI Agent 用到日常工作中，却遇到了一个特别让人抓狂的问题：
AI 的能力越来越强，干活的速度却不一定越来越快。
尤其是我最近使用的 DeepSeek Harness，简称 DSH。
有时候我只是让它修改一段 CSS，或者调整一下网页文案。
它却开始了一场漫长的思想斗争。
先思考。
再思考。
然后觉得有必要检查一下项目。
检查完项目，又觉得应该研究一下相关技术。
研究完技术，顺便上网搜索一下最新资料。
搜索回来，发现还需要继续思考。
我坐在电脑前，看着它不断输出工具调用记录。
突然产生了一种奇妙的感觉：
以前是老板给员工安排工作，现在是员工认真研究老板为什么要安排这项工作。
问题是，我只是想让你把按钮的圆角从 8px 改成 12px 啊！
于是，我开始研究一个问题：
能不能让 DSH 在简单任务上少思考、少调用工具、少上网，把时间真正花在执行上？
答案是可以的。
而且，不一定需要换模型，也不一定需要升级电脑。
一、首先，我们得搞明白：DSH 到底慢在哪里？
很多人看到 AI Agent 回答得慢，第一反应就是：
“是不是模型不够快？”
这个判断不能说完全错误，但也不全面。
因为 DSH 并不是一个单纯的聊天机器人。
它是一个能够调用工具、操作文件、运行命令和组织任务的 Agent 框架。
它的工作方式更接近：
接收任务 → 思考 → 选择工具 → 执行工具 → 获取结果 → 再次思考 → 继续执行 → 输出答案。
这里有一个容易被忽略的地方。
AI Agent 的总耗时，不只是模型生成答案的时间。
还包括模型思考、工具调用、网络请求、文件读取，以及多轮决策之间的等待。
假设我们让 DSH 修改网站上的一小段 CSS。
理想情况下，它只需要：
-
找到对应文件。 -
修改 CSS。 -
做必要检查。 -
告诉我修改完成。
但实际执行时，它可能先分析网站结构，再搜索 CSS 文件，读取相关页面，研究框架，甚至查询官方文档。
看起来特别认真。
但这就好像我让员工去楼下买瓶矿泉水。
他先研究了全球饮用水市场，再比较各大品牌的矿物质含量，最后组织了一场采购评审会议。
等他终于买回水，我已经渴得不想喝了。
所以，想让 DSH 变快，需要解决的不是单纯的模型速度，而是三个问题：
过度思考、过度调用工具、过度使用网络。
这三个问题互相影响，最后就形成了一个越来越慢的执行循环。
二、第一刀：别让所有任务都使用最高思考强度
这是我认为最应该优先调整的地方。
很多人在使用 AI Agent 时，有一种心理：
既然模型支持高级思考模式，那当然应该开最高啊！
毕竟买车都希望马力大一点，用 AI 难道还要省智商？
但问题是，并不是所有任务都需要复杂推理。
比如我平时做外贸独立站，经常需要 AI 帮我完成这些事情：
这些任务通常不需要最高级别的推理能力。
如果每次都调用高强度思考，相当于让一位博士教授认真研究如何给文件夹改名。
不是不能研究。
只是完全没必要。
我的解决方法：给不同任务分配不同思考强度
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
这里的 Flash、Pro 是模型档位，Off、Low、High 是思考强度。
需要注意，Off 并不意味着模型没有任何处理能力，而是关闭可配置的深度推理模式；不同模型的行为会有所区别。
我的使用原则非常简单：默认使用轻量配置，遇到真正复杂的问题，再主动提高思考强度。
DSH 的模型选择界面支持调整模型与 reasoning effort，也可以通过 /model 打开相关选择界面。
也就是说，不需要为了简单任务一直使用高强度思考。
三、第二刀：禁止 AI 没事就上网冲浪
这是另一个让我特别有感触的问题。
我们都知道，AI Agent 可以联网是好事。
比如我要分析美国宠物用品市场，研究 SEO 最新变化，或者调查竞争对手的网站结构。
联网能力非常重要。
但假如我只是让它修改本地项目里的按钮颜色呢？
它为什么还要打开网络搜索？
这里有一个很容易产生误解的地方。
AI Agent 拥有联网工具，不代表它知道什么时候应该克制自己。
模型在执行任务时，可能认为查询最新文档是一种更稳妥的做法。
于是就出现了这种情况：
我：帮我修改一下导航栏的背景颜色。
DSH：我需要先了解这个项目的技术结构。
DSH：我发现这里使用了 CSS。
DSH：为了确保兼容性，我应该查询一下相关规范。
我：？？？
这就好像我让装修师傅把墙刷成白色。
结果师傅告诉我，他准备先去参加一场国际涂料技术研讨会。
我的解决方法：默认关闭不必要的联网工具
可以按照实际任务把联网权限分成两种状态。
日常执行模式：
关闭不需要的 Web Search、网页浏览器或其他外部检索工具，只保留完成工作所需的本地能力。
研究分析模式：
当任务明确需要外部信息时，再启用搜索和浏览能力。
比如：
修改 CSS，不需要联网。
检查本地 WordPress 模板，通常不需要联网。
研究 2026 年最新 Ads 政策，需要联网。
分析竞争对手近期更新的页面，需要联网。
这里有一个非常关键的区别：
不是让 AI 永远不能联网，而是让联网从默认行为变成按需行为。
如果任务需要调用远程 API、获取依赖或者访问目标网站，当然也不能一刀切地禁止所有网络连接。
我们真正需要限制的是没有必要的外部研究。
四、第三刀：别让 AI 动不动就成立项目组
接下来这个问题，可能只有经常使用 Agent 的人才会深有体会。
现在很多 AI Agent 支持多 Agent 协作。
听起来非常厉害。
一个 Agent 负责分析需求。
一个负责写代码。
一个负责测试。
一个负责审核。
最后由主 Agent 汇总。
对于大型项目，这种协作模式确实很有价值。
比如我要搭建一个完整的外贸 B2B 独立站，包括网站架构、产品文案、SEO 策略和前后端开发。
让多个 Agent 分工执行，是合理的。
但问题是：
如果我只是修改一个网页标题，也需要五个 Agent 开会吗？
我想象中的场景是这样的。
老板：把首页标题改一下。
项目经理 Agent：收到，我安排内容专家处理。
内容专家 Agent：建议 SEO 专家确认关键词。
SEO 专家 Agent：需要技术专家评估影响。
技术专家 Agent：修改完成，建议测试专家复核。
测试专家 Agent：测试通过。
老板：我只是让你把 Factory 改成 Manufacturer 啊！
我的解决方法：小任务禁止自动拆分子 Agent
对于普通任务，我更倾向于让主 Agent 直接完成。
只有遇到下面几种情况，才考虑启用多 Agent 协作：
-
任务可以明确拆成多个独立模块。 -
不同模块之间有较少的依赖关系。 -
需要不同专业能力同时参与。 -
并行执行确实能够减少总耗时。
举个例子。
如果我要做一个完整的包装行业 B2B 网站，那么市场研究、产品分类、网站架构、SEO 关键词和技术开发可以适当分工。
但修改一段 CSS、调整一篇文案、修复一个小 Bug，完全没有必要。
记住：
Agent 越多，不代表效率越高。
多个 Agent 会增加模型请求、上下文传递以及结果汇总的成本。
对于简单任务，单个 Agent 往往更直接。
五、第四刀：别让 DSH 读完整个项目，只为修改一个文件
我在做独立站开发时，经常遇到一个问题。
项目文件很多。
尤其是 WordPress，插件、主题、模板、资源文件加起来，可能有成百上千个文件。
有时候我只想修改一个组件。
但 Agent 会先去理解整个项目。
这种认真负责的态度当然值得鼓励。
不过，认真不等于高效。
对于代码修改，我们真正需要的是：
只读取完成任务所必需的上下文。
比如我明确告诉它：
修改 assets/css/header.css 中的导航栏样式。
那它就应该优先检查这个文件。
如果确实涉及其他依赖，再扩大读取范围。
而不是一开始就全面扫描项目。
这里我建议大家养成一个习惯：
下达任务时，尽量给出明确的文件路径、修改位置和预期结果。
例如，不要只说：
“帮我优化一下首页。”
而是说：
“只检查首页 Hero 区域相关的模板及 CSS，优化移动端布局，保持其他组件不变。”
任务边界越明确，Agent 就越不容易在无关的文件之间来回折腾。
顺便解决另一个问题：对话历史太长
如果你经常在同一个 DSH 会话里连续开发网站，那么上下文会不断增加。
大量历史消息、工具结果和旧代码，都可能成为后续请求需要处理的内容。
DSH 提供了 /compact 功能，可以将较早的对话历史压缩为摘要。
这对于长时间开发特别有用。
不过，它并不是万能加速按钮。
压缩本身需要处理时间，也不能减少当前系统提示词或工具定义等固定开销。
所以我更建议：
一个明确阶段完成后，如果会话已经很长，可以考虑执行 /compact；不同项目尽量使用不同会话。
不要把半年前修改的导航栏、上个月研究的服务器配置，以及今天要写的产品页面，全都塞进一个无限延长的对话里。
AI 也是需要整理办公桌的。
六、第五刀：使用更精简的 Agent 预设
这一步比修改提示词更进一步。
DSH 采用插件化架构。
除了模型之外，Agent 能够使用哪些工具、接收哪些系统指令、调用哪些外部能力，都与当前的插件和 Agent 配置有关。
这意味着：
我们不一定需要让每一个 Agent 都配备一整套工具。
比如一个只负责修改文案的 Agent，通常不需要浏览器自动化、复杂工作流和多个子 Agent。
一个专门修改本地 CSS 的 Agent，也未必需要市场研究工具。
我的建议是，为不同工作准备不同能力范围的预设。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里的 Standard、Research、Full 是我建议的工作预设名称，不代表每个 DSH 版本都内置了这些同名预设。
官方确实提供了 Minimal 等精简方案，但具体工具清单要看当前配置。
而且，Minimal 不一定适合所有代码编辑任务。
例如，部分精简配置可能不包含常用的文件读取、写入或编辑工具，需要通过 Shell 完成操作。
所以不能单纯为了追求速度，把必要能力全部砍掉。
真正合理的做法，是让不同任务调用对应的 Agent。
简单工作轻装上阵，复杂工作再全副武装。
七、第六刀：直接给 DSH 立规矩，别让它自由发挥
前面讲的都是配置层面的优化。
但我发现还有一个非常实用的方法。
就是给 Agent 一套明确的工作规则。
因为很多时候，AI 并不是做不到快速执行，而是它没有接收到明确的效率要求。
于是它倾向于选择更谨慎、更复杂的执行流程。
我给自己整理了一套适合日常网页开发、文案修改和简单调试的提示词。
大家可以直接复制使用。
DSH 日常快速执行提示词
你是一个以执行效率为优先的 AI Agent。默认执行规则：1. 简单任务直接执行，不要先制定详细计划。2. 不主动联网搜索。只有任务明确需要外部信息，或者本地信息不足以完成任务时才联网。3. 不主动调用子 Agent。除非任务复杂且并行处理确实有必要。4. 只读取与当前任务直接相关的文件。不得无故扫描整个项目。5. 不要重复执行已经成功的工具调用。6. 工具失败时，先分析失败原因。同一种方案最多重试一次，不要无限循环。7. 修改代码时，优先采用最小改动原则。不要顺便重构无关代码。8. 只执行必要的验证。不要对简单修改进行无意义的全项目测试。9. 任务完成后直接汇报：修改了什么、结果如何、是否存在需要注意的问题。10. 如果遇到真实的安全风险、重要依赖或信息不足，允许进行必要的检查并简要说明。默认原则：简单任务快速完成；复杂任务充分思考；避免不必要的工具调用和联网。
这套规则的作用，是减少 Agent 在普通任务中不必要的自主扩展。
当然，提示词并不是硬性的权限控制。
如果你希望确保 DSH 不能调用某个工具，真正可靠的方法仍然是通过 Agent 预设、工具限制或插件配置控制权限。
两者结合，效果通常比只写一句“请快一点”更好。
八、还有一个专门控制 DSH 行为的插件
研究过程中，我还发现了一个社区插件：
dsh-terse-mode
这个插件的目标，就是让 DSH 的行为更加精简。
它提供多个可调整的精简级别，并可以分别控制推理强度、Web Search 和子 Agent 的使用。
这正好对应我们前面讨论的几个核心问题。
但这里我不建议大家看到插件就立刻安装。
因为 DSH 仍在快速迭代，部分插件可能存在版本兼容性问题。
而且，社区插件毕竟不是官方核心功能。
我更建议先备份配置、检查插件源码和所需权限，再在测试环境安装。
插件不一定比手动配置更快，但可以帮助经常切换执行模式的人减少重复操作。
如果你没有插件开发经验，先调整模型、工具权限和提示词，就已经能够开始验证效果。
不需要为了优化一个工具，再把自己变成插件开发工程师。
九、我最推荐的 DSH 配置，直接照着思路调整
我更建议采用下面这套配置策略。
日常工作模式
适合完成大部分普通工作。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/compact
|
复杂项目模式
适合处理网站架构、安全问题、多文件开发和复杂故障。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我要特别强调一点。
这些是值得优先尝试的配置策略，而不是经过统一性能测试得出的最佳参数。
不同模型、DSH 版本、网络环境、插件组合和任务类型，都会影响最终效果。
简单任务降低思考强度，通常有利于减少推理开销。
但如果任务本身很复杂，过度限制推理和工具调用，也可能导致错误、返工，最后反而更慢。
优化的目的不是让 AI 永远少做事。
而是让它少做不必要的事。
十、怎么判断优化到底有没有效果？
很多人在优化 AI 工具时，容易陷入一个误区：
感觉变快了，就认为成功了。
但真正想知道有没有改善，最好还是做个简单的对照测试。
比如选择三个我们日常经常执行的任务：
任务 A：修改某个 CSS 属性。
任务 B：优化一段产品英文文案。
任务 C：修复一个需要检查两三个文件的小 Bug。
然后分别使用不同配置执行。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
重点记录四项数据：
总耗时、首次响应时间、工具调用次数、任务是否正确完成。
其中最重要的，并不是工具调用次数越少越好。
如果一个 Agent 只调用一次工具，却把网站弄坏了，那当然不能算优化成功。
我们真正追求的是：
在保证结果正确的前提下，减少不必要的等待。
可以每组重复测试几次，尽量使用相同任务和相同环境，比较中位耗时，而不是只凭一次体验下结论。
这比单纯比较“哪个模型更聪明”更有意义。
十一、最后，我想聊聊 AI Agent 最容易被忽略的一件事
现在的 AI Agent，正在从聊天工具逐渐变成真正的工作工具。
尤其对于外贸企业来说，这种变化会越来越明显。
我们可以让 Agent 帮忙搭建独立站、开发落地页、管理产品内容、分析竞争对手、检查 SEO 问题，甚至参与整个数字营销流程。
但随着功能越来越丰富，新的问题也出现了。
Agent 可以调用的工具越来越多。
可以访问的信息越来越广。
可以独立完成的任务越来越复杂。
于是，我们很容易产生一种错觉：
AI 做的步骤越多，说明它越专业。
实际上，这两者完全没有必然关系。
有些任务需要认真研究，有些任务就应该直接执行。
就像一个成熟的员工，应该知道什么时候需要开会讨论，什么时候只需要把事情做完。
一个优秀的 AI Agent，也应该具备这种判断能力。
我甚至觉得，未来评价 AI Agent 的标准，不应该只有模型智商、推理能力和工具数量。
还应该包括：
它能不能理解任务的复杂程度？
能不能主动控制执行成本？
能不能避免无意义的工具调用？
能不能在正确的时间停止思考，开始干活？
这些能力，可能比单纯提高模型参数更接近真实的生产力。
所以，如果你的 DSH 也经常陷入长时间思考、反复调用工具、动不动就联网搜索的状态，不妨从今天开始尝试调整。
先降低普通任务的思考强度。
再限制不必要的联网和子 Agent。
然后精简工具和上下文。
最后，用一套清晰的执行规则约束它。
说到底，我们使用 AI Agent，是希望它能帮我们节省时间。
而不是让我们花更多时间，研究如何让它节省时间。
AI 可以深度思考，但没必要每次都写一篇博士论文。
毕竟，我只是想改个按钮颜色。
不是准备参加图灵奖答辩。
如果你也在使用 Codex、Claude Code、DSH 等 AI Agent 来处理外贸建站和营销工作，欢迎交流你的使用体验。
毕竟，AI 时代最珍贵的资源，可能已经不是算力，而是我们盯着屏幕等 AI 干活时，那一点点逐渐消失的耐心。
推荐阅读：
AI 爬虫都来我网站了，为什么 ChatGPT 还是不推荐我？
外贸独立站用AI图，会被Google抓包吗？
网站维护费是买什么？外贸老板该验收这8项
2026年了，我发现SEO最该优化的，居然不是关键词！
做了10年独立站，我受够了那些“反人类”的SEO工具，干脆自己造了一个