企业官网建设流程全解析

我一直觉得，编程智能体（Coding Agent）真正走向成熟的标志，不是模型变聪明了，而是交互形态变了。这段时间我密集使用了 Claude Code，也仔细研究了 Hermes Agent 这类带工作台的项目，一个感受特别明显：顶级的 Coding Agent 正在集体放弃纯 Chat 模式。所谓纯 Chat 模式，就是把大模型当成一个更聪明的问答机器人，你问一句它答一句，写代码全靠复制粘贴。这种用法不能说没用，但它和“Agent”这个词基本没什么关系。今天这篇就想把这件事拆透：为什么 Claude Code、Hermes Agent 都不约而同地走向终端命令、工具调用、任务工作台，以及如果你想把它们真正用起来，应该从哪下手。

1. 纯 Chat 模式已经被“Agent 循环”替代

1.1 纯 Chat 模式到底卡在哪

先说纯 Chat 模式的本质问题。打个比方，纯 Chat 模式就像一个只会动嘴的顾问，它能告诉你怎么改代码，但不会帮你打开文件、跑测试、修报错。你让它改一个 300 行的模块，它给你一段新代码，你得自己找到文件、找到函数、粘贴进去；跑出报错，你又得把报错信息复制回聊天窗口。一次两次还能忍，一个工程改十次，人就麻了。

这不是懒不懒的问题，而是信息损耗。代码经过复制粘贴会丢缩进、丢格式，报错信息在聊天窗口里堆得越来越长，真正的上下文反而被挤占。纯 Chat 模式下，你维护的不是“任务状态”，而是一长串口语对话记录。这种形态适合问思路、写小片段，但扛不住真实工程里“读文件、改代码、跑测试、修 bug”的循环。

更关键的是，纯 Chat 模式没有工具概念。它不能执行 shell 命令，不能 glob 搜索文件，不能主动 git diff。所有需要动真格的操作，都得靠人肉中转一遍。你会发现，聊得越多，你干的杂活越多，AI 反而像个只会指路的教练。

1.2 Coding Agent 的运行核心：感知-规划-行动-验证

真正的 Coding Agent 走的是另一条路：感知、规划、行动、验证，四步构成一个闭环。

先用 Claude Code 举例。你在终端里让它“修一下这个模块的 bug”，它不会直接抛出一段代码就完事。它会先感知：查看目录结构、读相关文件、定位可能出问题的函数；然后规划：是改参数校验，还是调整异常处理；接着行动：直接修改文件内容，必要时执行测试命令或 lint；最后验证：看测试结果、看 diff，如果还不满意，就再次回到感知阶段。

这个过程里，模型本身不是执行者，而是决策者。真正跑命令、改文件的是一个“执行框架”，也就是 Claude Code 社区里常说的 harness。模型负责在每一轮决策“下一步调用哪个工具”，框架负责把工具结果拿回来，再喂给模型继续决策。这就是 Agent 循环。

纯 Chat 模式是“人绕路”，Agent 模式是“人审路”。人从搬运工变成监督者，效率差距自然就出来了。这也是我判断一个工具是不是真 Agent 的标准：它能不能在一个任务里连续调用多次工具，并且在没有人工输入的情况下收敛到一个结果。

1.3 终端、桌面工作台为什么比聊天窗口更契合编程

那为什么顶级客户端都选终端或工作台，而不是在聊天窗口里加按钮？原因很简单，终端面向的是“任务”，聊天窗口面向的是“对话”。

终端有标准输入输出、有管道、有文件系统，这些是编程世界的母语。Claude Code 在终端里可以直接读写文件、执行命令，每次操作都有日志、有退出码，结果是可以被后续步骤继续消费的。聊天窗口没有这些接口，只有一串串气泡。

更实际的一点是，终端天然有审批机制。命令要不要跑、文件要不要改，终端交互可以停下来问用户；而聊天窗口里的推荐按钮，本质上还是让用户手动去点。另外，桌面工作台（比如 Hermes Agent 这类项目提供的 GUI）解决的是另一个问题：当你有多个任务在跑、需要看负载、需要审阅工具调用时，需要一个“控制面板”而不是“消息列表”。所以你会看到，Claude Code 认真做 CLI，Hermes Agent 认真做工作台，方向不同，但都在远离纯 Chat。

2. Claude Code 拆解：终端原生的编程智能体

2.1 从“聊天机器人”到“harness”的转变

Claude Code 是我目前用得最顺的编程智能体。它不是网页对话框的套壳，而是在终端里跑起来的一个交互式程序。安装完之后，你在项目目录下敲claude，就进入一个命令行会话。这个会话里，你可以直接说“给这个项目加一个日志模块”，或者“把 test 目录下所有文件的命名统一成 kebab-case”。

它的架构核心是 harness 机制。模型并不直接碰文件系统，而是通过一串工具调用来完成任务。Claude 模型在每一步决策中会输出一个结构化意图：读取哪个文件、执行什么命令、修改哪些行；本地 harness 负责把这些意图真正落地，并把结果写回上下文。

这个设计的厉害之处在于，模型不用“记住”整个文件内容，它需要什么就现读现用。文件大了也不怕，它可以只读取函数片段、只搜索关键词。对比纯 Chat 模式里动辄把整个文件贴进去的做法，这种按需拉取的方式既省 token，又减少幻觉。

2.2 安装：macOS、Windows、Ubuntu 三条路线

安装这块，网上教程很多，但有几个细节值得说清楚。

macOS 和大部分 Linux 环境最直接的装法是通过 npm：

npm install -g @anthropic-ai/claude-code

装完后确认一下 Node.js 版本，太老的版本会直接报错，建议至少 LTS 版本。Windows 下面有两条路：一个是直接用原生命令行环境，另一个是装好 WSL 后在 Linux 子系统里跑。我实测下来 WSL 路线更省心，文件路径、权限模型都和 Linux 对齐，遇到问题也好搜解决方案。Ubuntu 和 Debian 系没太多幺蛾子，Node 装好、npm 全局路径加进 PATH，基本就能跑。

官方也提供了桌面版安装包。如果你完全不想碰终端，桌面版可以让你用图形界面进入会话，但我个人不太推荐把桌面版当作主要使用方式，因为 Claude Code 的价值恰恰在终端工具链里。桌面版更像给非技术场景准备的入口，编码场景里 CLI 的折腾空间大得多。

安装完成后，在任意项目目录执行claude就可以初始化。第一次跑会引导你完成登录或配置 API Key，这一步不用急，后面讲设置时细说。

2.3 命令、审批与权限：为什么必须“能干活”

Claude Code 里有大量斜杠命令，比如/model切换模型、/clear清空会话、/compact压缩上下文、/help查看帮助。这些命令最大的价值是稳定和可发现，你在聊天窗口里可能要靠猜来问模型，而斜杠命令的存在让你随时有一套确定性操作。

但真正让 Claude Code 和纯 Chat 拉开差距的，是权限与审批模型。它执行命令、修改文件都不是“无脑干”，而是有一套用户确认机制。比如第一次在会话里让它删除文件，终端会停下来问你“允许执行删除吗”，你确认后它才继续。你可以配置白名单，让某些低频且安全的命令自动放行；也可以更保守地对所有命令保持逐个询问。

我强烈不建议开启全局免确认模式。曾经有一次我为了省事，在某个项目里放开了所有权限，结果 AI 在重构时顺手删掉了一个我还没合并的分支目录，好在有 git 兜底。从那以后，我对权限模型的态度就一句话：审批成本永远低于事故成本。

bypassPermissions这个设置听起来很香，但它是风险开关，不是效率开关。想让流程顺，更好的做法是把命令白名单细化到具体命令，比如只允许npm run test和git diff自动执行，其他一律先问。

2.4 用 cc-switch、本地模型、VSCode 把 Claude Code 装进自己的工具链

Claude Code 默认走 Anthropic 官方模型，但它用的 API 协议可以被替换。社区里很常见的做法是借助 cc-switch 这类第三方配置工具，把请求指向兼容 Anthropic 协议的其他模型服务，比如 DeepSeek、通义千问 Qwen、智谱 GLM 的 API。

cc-switch 的逻辑很朴素：它管理多份 provider 配置，切换时改写当前环境里的ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。配置一般长这样：

{ "providers": [ { "name": "deepseek", "apiUrl": "https://your-endpoint.example.com/anthropic", "apiKey": "sk-xxx", "model": "deepseek-chat" }, { "name": "qwen", "apiUrl": "https://your-endpoint.example.com/anthropic", "apiKey": "sk-xxx", "model": "qwen-max" }, { "name": "glm", "apiUrl": "https://your-endpoint.example.com/anthropic", "apiKey": "sk-xxx", "model": "glm-4-plus" } ] }

这里要特别提醒一点：不是所有模型都完整支持 Claude Code 的 harness 特性。Claude Code 内部有很多针对 Claude 模型优化的系统提示和工具使用约定，换成第三方模型后，写简单脚本、改结构清晰的项目问题不大；但一旦任务复杂，模型能力不足时就容易在工具调用里绕圈。我实测下来，中等任务量可以切第三方，关键任务我还是回到 Claude 模型。

VSCode 插件方面，官方有 “Claude Code for VS Code” 扩展。它不是另起炉灶，本质上还是调本地的 Clude Code CLI，只是把交互界面放进了编辑器侧边栏。选中一段代码，在插件面板里让它解释、重构或补测试，上下文会自动带上选区内容，比手动复制粘贴舒服很多。如果你平时用 VSCode 开发，这个插件值得一试。

3. Hermes Agent 拆解：带着工作台和记忆库的“电脑操作员”

3.1 CUA 路线：从代码走到电脑界面

如果说 Claude Code 是“编程原住民”，那 Hermes Agent 这类项目想做的是“电脑操作员”。它走的是 CUA（Computer Use Agent）路线，目标不只是读写代码文件，而是操作界面上能看到的软件：打开浏览器、填写表单、整理文档、操作本地应用。

这条路线比纯代码工具更难，因为界面是视觉化的、非结构化的，agent 要先“看懂”屏幕内容，才能谈“操作”，执行完之后还要再回看屏幕确认结果。但它的想象空间也更大。纯 Chat 模式只能处理文本输入输出，CUA 路线处理的却是你的整个数字工作环境。

我用 Hermes Agent 的一个典型场景是批量整理本地文档：把散落在多个目录的 Markdown 文件按标题结构归类、补上缺失的前置元信息、把重复内容合并。这类活如果靠聊天窗口来做，我得自己找文件、自己写脚本；如果靠模型“建议”，它只能给我一段脚本；而工作台式 agent 可以自己在目录里逛、读文件、改文件、汇报结果。这才是 Agent 该有的样子。

3.2 第三方工作台：agent 的控制室

Hermes Agent 让我觉得最有价值的部分，是它的桌面工作台。工作台这个东西，纯 Chat 里永远长不出来，因为聊天窗口是线性的，而工作台是并行的、可管理的。

工作台解决的核心问题是“多任务管理”。当你让 agent 同时处理几件事，比如一个任务在跑测试，一个任务在整理代码注释，一个任务在收集资料，这时候你需要一个仪表盘来查看每个任务的状态、暂停某个任务、审查工具调用记录。工作台本质上是一个控制室，它把 agent 的运行内部状态暴露给了人。

这里有个认知转变：agent 不是“聊天的对象”，而是“你要管理的下属团队”。既然是团队，就得看他们的工作日志、任务队列、执行结果。工作台就是干这个的。Claude Code 社区里大家也会做第三方可视化管理面板，这个需求不是个例，而是 agent 规模化使用后的必然结果。

3.3 Obsidian 记忆库：把 agent 的长期记忆落成文件

另一个让我眼前一亮的点，是 Hermes Agent 生态里和 Obsidian 的联动。Obsidian 是本地 Markdown 笔记库，可以看作一个纯文本的知识管理系统。很多 agent 项目会把 Obsidian 当长期记忆库：任务执行过程中的决策、项目背景、用户偏好，都可以写成 Markdown 笔记存进一个 vault 目录；下一次任务开始前，agent 先检索这些笔记，再制定计划。

这个设计解决的是纯 Chat 模式里最致命的短板——失忆。纯 Chat 模式每次新会话都是一张白纸，你上次跟它说过的偏好、它上次查到的背景知识，全部清零。而把记忆“文件化”之后，记忆就和代码一样，成了可检索、可版本管理、可审计的东西。

说白了，笔记即数据库，Markdown 即接口。这个方法不仅 Hermes Agent 能用，任何 agent 项目都能借鉴。哪怕你只是用 Claude Code，你也可以手动在项目里放一个AGENTS.md之类的文档，把项目的架构约定、常用的命令、易踩的坑写进去，让每次会话都能读到，相当于给 agent 装了一个轻量记忆库。

3.4 安装与配置工作台的关键步骤

Hermes Agent 这种项目迭代速度快，我没有办法给你一套永远正确的安装命令，建议直接以官方仓库 README 里的 Quickstart 为准。但通用步骤是稳定可参考的：

第一步，准备运行时环境。多数这类项目基于 Node.js 或 Python，先装好对应运行时，再用包管理器拉取项目本体。第二步，配置模型 provider。它同样支持 Anthropic 协议或 OpenAI 兼容协议，你可以填官方模型，也可以填本地模型或第三方 API。第三步，初始化工作台。通常在命令行里执行项目的启动命令，会拉起一个本地 GUI 面板，里面能看到任务列表、日志、审批请求。第四步，接 Obsidian vault。配置一个本地笔记目录路径，让 agent 可以读写那个目录，长期记忆就算落地了。

装好之后，建议先给一个小任务练手，比如让它整理一个指定文件夹里的文件名。第一次跑 CUA 路线时别期待完美，界面操作这种事的误差率还比较高，但你已经能直观感受到它和聊天式工具的差异：它会自己打开目录、自己看内容、自己做决定。

4. 顶级 Coding Agent 放弃纯 Chat 模式的四个核心原因

4.1 上下文有限，闭环探索根本跑不起来

纯 Chat 模式的第一个硬伤，是上下文窗口不够用。真实编程任务不是一步到位的，它需要反复探索和修正：读文件发现原因，改代码引入新问题，跑测试看到新报错，再回来修。这个“探索-纠正”回路里，每一步都要消耗上下文。聊天窗口里堆积的是闲聊格式的对话，上下文塞满后，模型会遗忘最早的关键信息。

Agent 模式不一样。它每次工具调用都有结果返回，结果自动进入下一步，不需要用户手动搬运。Claude Code 还实现了上下文压缩，长任务跑到一半，系统会主动把早期内容做摘要、释放窗口空间，让模型继续专注于当前最相关的信息。纯 Chat 模式想做到这点，就得靠人自己“总结一下之前我们说到哪了”，太原始了。

4.2 行动权限：Chat 只能建议，Agent 必须审批

第二个原因，也是我认为最本质的：行动需要权限，权限需要模型比 Chat 更复杂。纯 Chat 模型没有权限概念，因为它永远不碰真实环境；但 Coding Agent 一定要碰，它要改文件、跑命令，所以必须有审批边界。

Claude Code 的权限模型是分级的：文件编辑和命令执行分别有独立的确认策略，还可以设置白名单、按项目维度保存偏好。这套设计让“AI 自主干活”和“防止 AI 破坏环境”之间有了缓冲带。做产品的人都明白，一个功能没有被运用起来，常常不是因为功能不够强，而是因为不够安全。没有审批边界的纯 Chat 模式，恰恰是那种“功能强但不安全”的形态。

4.3 可审计、可复现、可调度：工程化的最低要求

第三个原因是工程化。你在聊天窗口里让 AI 写了一段代码，这件事如何留痕？如何让下一个接手的人知道这次改动是 AI 做的、为什么这么做？纯 Chat 的聊天记录本质上是一段不好解析的文本流。

Agent 的地盘上，一切都有结构化记录：执行了哪条命令、退出码是多少、改了哪些文件、diff 长什么样，甚至每个步骤用了哪个模型、消耗了多少 token。这种可审计性对个人无所谓，但对团队和自动化流程是底线。更进一步，CLI 形态可以被脚本调用，可以在 CI 里跑，可以挂在任务系统里调度；聊天窗口没法被编排。所以你会看到 Claude Code 提供了-p这类非交互模式，目的就是给自动化流程留接口。

4.4 从对话流转向任务流

纯 Chat 的模式是对话流，一问一答；Agent 的模式是任务流，一任务一闭环。对话流更适合“人跟人聊天”的隐喻，但工作不是聊天，工作是“定目标、拆步骤、执行、检查”。

当你需要挂起一个任务、过几分钟再回来继续看，或者同时并发三个任务，对话流的线性结构就崩了。任务流有状态：待执行、执行中、等待审批、已完成、失败。你可以暂停、可以重跑、可以只重跑失败的那一步。这种控制和可视化，是纯 Chat 模式根本给不了的。

4.5 一张表看三种形态的定位

这张表基本解释了我为什么从纯 Chat 迁移到 Agent：不是 Chat 不好，而是定位完全不同。Chat 适合发散，Agent 适合收敛；Chat 适合解释世界，Agent 适合改变世界。

5. 实操：从零接入 Claude Code 并接上第三方模型

5.1 登录、注册与配置文件的初始化

很多人纠结注册账号和不注册有什么区别。简单说，不注册也能运行 Claude Code，前提是你有自己的 API Key 或者第三方兼容服务的配置；但注册登录后，你才能使用官方订阅相关的模型额度，以及配置同步等账号能力。如果你拿它当主力开发工具，还是建议完成登录，官方能力配合 Claude 模型整体表现更完整。

初始化的路径一般会引导你完成这些事：

claude

第一次启动会检查登录状态，按提示完成 auth 流程。之后在项目目录里会有配置文件保存你的偏好，包括权限设置、模型选择、工作目录等。团队开发时，建议把通用配置提交到仓库，让新成员克隆后少踩配置坑。

5.2 直接执行终端命令的设置思路

Claude Code 的“直接执行终端命令”不是靠按钮，而是靠工具调用。你在会话里说“看看这个目录下哪些文件最近改动过”，它会自动执行git status或ls -lt这类命令；你说“跑一下测试”，它会执行npm test。默认情况下，命令执行前会征求你的同意，这正是权限模型发挥作用的地方。

如果你希望某些安全命令不被反复询问，可以在权限配置文件里加入白名单。比如把npm run test、git diff列为免审批，其他命令保持手动确认。我的建议是：白名单宁少勿多，高频且无破坏性的命令才值得加。

5.3 接 DeepSeek、Qwen、GLM 的第三方服务配置

第三方模型接入的核心就是改两个环境变量：ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。一些模型服务商提供 Anthropic 协议兼容的接口，直接用这类接口就能省去协议转换。

用 cc-switch 管理多套配置的好处是方便来回切。开发模式下用便宜的第三方模型跑日常任务，关键上量任务切回 Claude 模型。切换时只需在 cc-switch 里选中目标 provider，它会帮你更新当前会话的环境。不想用工具也可以手动导出：

export ANTHROPIC_BASE_URL="https://your-endpoint.example.com/anthropic" export ANTHROPIC_API_KEY="sk-xxx" claude --model deepseek-chat

这里必须提醒一句：第三方模型的工具调用能力差距很大。拿它写简单脚本时感觉不错，一旦任务链条变长，模型可能忘记自己下一步该干什么，甚至反复执行同一命令。建议把任务拆小，让每一次任务都在一个清晰的范围内收敛，不要指望便宜模型驾驭复杂工程。

5.4 用 LM Studio 调用本地模型

热词里出现了“claude code 调用 lmstudio 的本地模型”，这也是很多人关心的问题。LM Studio 可以在本地起一个 OpenAI 兼容的服务，但 Claude Code 默认是 Anthropic 风格请求，所以中间需要一个协议适配层，要么用一个支持 Anthropic 兼容接口的本地网关，要么用工具把 Anthropic 请求转成 OpenAI 请求，再把响应转回去。

LM Studio 本地服务的地址通常是http://localhost:1234/v1。配置到 Claude Code 本地模型时，ANTHROPIC_BASE_URL指向这个地址对应的适配端口，API Key 随便填一个占位符即可，模型名写成你在 LM Studio 里加载的模型名，比如qwen2.5-coder-7b-instruct。

本地模型对硬件要求不低，7B 级别模型写简单工具类脚本完全够用，但要重构大工程，体验经常是灾难级别。我的定位是：本地模型适合离线场景、隐私敏感场景，以及“练习理解 agent 工作流”的探索场景。真要干活，远程大模型还是主力。

5.5 把 Claude Code 接进 VSCode 和飞书机器人

VSCode 接 Claude Code，安装官方扩展后，它会自动识别本地装好的 CLI，然后在编辑器侧边栏里增加一个 agent 面板。你可以选中代码片段，右键发送到面板；也可以打开某个文件，让它直接基于当前文件做修改。扩展面板本质上是 CLI 的图形前端，所以你在终端里配置的模型、权限，在插件里同样生效，不需要重复配置。

飞书接 Claude Code 是团队场景里比较高频的需求。思路很简单：飞书开放平台创建一个机器人，配置事件订阅回调地址；回调服务收到消息后，用子进程调用 Claude Code 的 CLI 非交互模式，把输出回传给飞书。

一个最小实现的核心逻辑大概是：

const { execSync } = require('child_process'); function handleMessage(text) { if (!text.startsWith('/claude ')) return; const prompt = text.replace('/claude ', ''); const result = execSync(`claude -p "${prompt}" --output-format json`, { timeout: 120000, }); return JSON.parse(result).result; }

这里有个安全红线：绝对不能把没有鉴权的回调服务直接暴露在公网。飞书事件回调自带签名校验，服务端必须校验签名后再执行命令，最好再加一层固定触发词白名单，防止任何群里的人都能让你电脑跑命令。我见过有人图方便把回调地址公开，结果群里一个手滑导致本地跑了一堆危险命令，还好只是开发机。这种远程触发 agent 的能力，本质上是把你的电脑变成了一个可被远程调度的执行器，安全设计永远是第一位的。

6. 常见问题速查表与避坑经验

6.1 安装与运行阶段的高频报错

我把这段时间踩过的坑整理成一个速查表，遇到问题先对照看看。

这些坑大多不是配置写错，而是环境不一致。排查时先看版本、再看 PATH、最后看网络策略，基本能覆盖大部分情况。

6.2 接入第三方模型时的典型坑

第三方模型接入最大的坑，是“看起来能跑，实际会绕圈”。Claude Code 的 harness 设计是高度依赖模型遵循系统提示和工具协议，能力不够强的模型可能在工具调用序列里自我循环，反复执行同一条命令却不收敛。

另一个坑是端点协议差异。不同服务商的“Anthropic 兼容”粒度不一样，有的只是路径兼容，有的在请求体和响应体上做了简化，导致 Claude Code 拿到异常返回后重试。遇到这类问题，先确认服务商文档里写的是不是真正的 Anthropic 协议兼容，再看社区里有没有用同一服务商接 Claude Code 的案例。

6.3 我一直坚持的几个使用习惯

最后聊几个我从实际使用中沉淀下来的习惯，算不上标准答案，但对新手很管用。

第一，启动 agent 之前先提交一次 git。这句话我几乎逢人就讲。Agent 干活再怎么聪明，也可能在重构时删掉你不想删的东西。有 git 兜底，随便折腾；没有 git，一次事故就能让人长记性。

第二，不要在家目录启动 Claude Code。在哪个目录启动，它就默认把哪个目录当项目根目录。在家目录启动，它可能把你的个人配置、文档当成项目文件来处理，既混乱又危险。给每个项目建一个独立工作目录，让 agent 的活动半径受控。

第三，把项目约定写进文档。我会在项目根目录放一份代理约定文件，写清楚项目结构、常用命令、禁忌事项。Claude Code 每次会话都能读到，第三方模型也能受益，相当于给无状态的 agent 加了一个轻量记忆层。

第四，区分“探索模式”和“执行模式”。探索模式下我允许 agent 随便读文件、查信息，但禁止写文件和执行命令；执行模式下才放开编辑权限。这套思想跟 Claude Code 的权限模型天然契合，我也建议你在配置里显式区分这两种使用场景。

我现在的日常工作流，已经很少有“打开聊天窗口复制粘贴代码”的环节了。需要改代码，就直接在项目目录里启动 agent，让它自己看、自己改、自己测，我只负责审结果和踩刹车。这个转变带来的效率提升，比换一个更强的模型更明显。如果你还停留在把 AI 当聊天框用的阶段，不妨从一个小项目开始试试：先让 agent 帮你补测试，再让它帮你重构函数，最后试着把整个小任务扔给它闭环跑一遍。等你能接受“把任务交给它跑”而不是“和它一问一答”之后，才算真正用上了 Coding Agent。