企业官网建设流程全解析

最近被问得最多的一个问题：本地写了个 Agent，跑起来很顺，能爬网页、能写代码、能自动整理文档，但一放到服务器上接真实用户，就开始花样翻车——要么死循环卡住，要么乱调用工具，要么并发一上来直接把 API 配额打爆。问到最后，大家都会落到同一句话：个人工具和生产 Agent 的本质区别到底在哪。

这个问题值得掰开讲。原因很简单，“Agent”已经是这两年最热的技术词之一，框架、教程、热词满天飞，什么 agent 架构、多 agent、agent 记忆、agent skill，但大多数讨论都停在“怎么让模型更聪明”，很少有人聊“怎么让一个 Agent 在没人盯着的时候还能靠谱”。而后者，恰恰是个人工具和生产 Agent 的分水岭。

这篇文章不聊概念，就聊工程。我会从 harness 和 agent 的区别、记忆与 Skill 的工程化、并发可靠性、安全边界、框架选型这几个角度，把个人工具和生产 Agent 之间的差距一层层剥开，最后给你一条能落地的升级路径。

1. 先对齐一个基本认知：Agent 到底是什么，不是什么

1.1 热词背后的误解：把“循环”当成了 Agent

关于“agent是什么”，网上已经吵翻了。最反直觉的事实是：真正常看到的所谓 Agent 项目，本质上就是一个循环——模型决定下一步干什么、执行工具、把结果喂回去、重复，直到目标完成。这个模式本身没什么门槛，核心结构长这样：

while not goal_achieved(task): next_action = model.decide(observation) observation = execute(next_action)

个人工具到这个程度就可以用了。我自己写第一版 Agent 时也是这样，一个 while 循环 + 一个模型 API + 三四个工具函数，跑通以后特别兴奋，觉得“搞定了”。但实际上，这个循环能成立的前提是：有个人全程盯着屏幕，看到它卡住就中断，看到它调用错了工具就手动纠正，token 跑冒了也无所谓。

生产 Agent 面对的条件完全不同：没有人在旁边盯着，一次任务可能跑几十分钟，用户可能在同一时间提交成百上千个任务，每一次工具调用的副作用都可能影响真实数据。这时候，“能跑通一个循环”和“能作为一个系统稳定运行”之间，隔着一整条工程鸿沟。

1.2 分水岭不是模型，是“系统承诺”

很多人以为个人工具升级成生产 Agent，就是把模型从便宜款换成旗舰款，或者换一个更炫的框架。我的看法恰恰相反：两者的本质区别，在于你对这个系统做出了什么样的承诺。

个人工具是“帮我干完一件事”，坏了就坏了，重来一遍就行。生产 Agent 是“替我一直干活”，它必须处理多用户并发、任务中断恢复、数据隔离、权限控制、成本核算、行为审计，这些每一件都是隐性的、平时看不见的工程义务。

我把个人工具和生产 Agent 拉了一张对比表，每次做技术方案时都会回来过一遍：

这张表最后落在一个词上：承诺。个人工具是“帮我干完一件事”；生产 Agent 是“替我持续地、安全地、可被追责地干一件事”。后面所有技术选型，本质都是为了兑现这个承诺。

2. harness 与模型：被严重低估的外在编排层

注意一个现象：现在圈子里讨论“harness 和 agent 区别”的人越来越多。这是个很关键的信号——大家开始意识到，决定一个 Agent 生产级靠不靠谱的，不是模型本身有多聪明，而是套在模型外面那层控制装置有多严。

2.1 harness 是什么：从“马具”到“驾驭层”

Harness 的英文原意是马具、挽具，引申出来就是“驾驭”的意思。放到 AI Agent 语境里，harness 指的是把模型、工具、记忆、权限、控制流组装在一起，并且约束行为边界的那一层外壳。

这里要说清楚：agent 本身是能力（能推理、能调用工具、能规划），harness 是规则（允许调用什么、最多跑几步、失败怎么办、越界怎么拦截）。我见过太多人写 Agent 时把精力全花在 prompt 和模型选择上，觉得“模型聪明了，什么都不用管”。这是最大的误区。一个再聪明的模型，如果不给它套 harness，放到生产环境里就是一头没有缰绳的马：你不知道它会访问哪个文件、调用哪个接口、编出什么理由来绕过你的限制。

生产级 Agent 的 harness 不只是一个开关或一层拦截，它应该是整个系统里最厚的代码层。我自己的经验是，真正上线的 Agent 项目里，模型相关的代码占比很小，干掉一半以上的代码量都在 harness 上——队列、状态机、网关、审计、重试、权限，全是为“模型不听话”兜底的东西。

2.2 生产 Agent 的 harness 至少要管的五件事

个人工具不需要 harness，因为你自己就是 harness——你的眼睛和手在兜底。生产 Agent 没有这个条件，所以下面五件事必须显式地写进代码里：

1. 生命周期编排：任务队列、状态机、暂停与恢复。一次 Agent 任务很可能要跑几十步，中途可能遇到限流、断电、进程被杀。没有状态机，这些情况一发生，任务就永久丢失。

2. 工具网关：所有外部能力不能直接暴露给模型，必须经过一个网关。网关做三件事：校验参数格式、检查权限、设置超时。我见过一个线上事故，模型把日期参数传错了格式，工具直接删了对应用户的历史数据，就是因为少了一层参数校验。

3. 模型网关：统一管理多个模型供应商，做限流、重试、降级和成本核算。生产环境不能假设某个模型永远可用，更不能假设它的输出永远是合法 JSON。

4. 安全边界：沙箱执行、敏感操作拦截、数据出口白名单。这个后面第 5 章细讲。

5. 可观测与审计：每个决策、每次工具调用、每段模型输出都要落 trace。出问题的时候，你要能回答“它当时为什么这么做”。

2.3 大厂开始把 harness 本身当产品卖，说明方向已经明确

如果你留意过 OpenAI 的 Codex CLI、Anthropic 的 Claude Agent Skills 这类产品，会发现它们的核心亮点不只是模型，而是一整套命令行 Agent 的 harness：沙箱、工具协议、权限确认、会话管理、技能目录。为什么大厂要专门做这些？因为单靠模型 API，普通开发者很难自己搭出靠谱的 Agent。

把 harness 标准化，本质上是把“生产级”的门槛往下拉。这也解释了为什么现在第三方 Agent 工作台和“把 skill 作为标准协议”的玩法越来越流行——大家都在抢同一个位置：让 Agent 的开发不再从裸循环开始，而是从一套成熟的外在编排层开始。如果你还在“while 循环 + prompt”的阶段，至少要知道，这套东西离生产还很远，而 harness 恰恰是你要补的第一块大板。

3. 记忆、Skill 与上下文：从“现用现查”走向“状态工程”

热词里出现频率最高的一批词，除了“agent 是什么”，就是 agent 记忆、agent skill 教程、ai agent token 是什么意思。这些词看起来是三个方向，其实说的是同一件事：生产 Agent 必须有状态管理的能力。个人工具可以“现用现查”，把东西全塞在上下文里；生产 Agent 必须把记忆、技能和 token 当成工程对象来设计。

3.1 Agent 记忆的三层架构，个人工具可以不管

个人工具的记忆通常就是上下文窗口——把所有历史对话、搜索结果全塞进一个 prompt，模型自然“记得”。但生产环境不行，原因有三个：token 成本、上下文长度限制、以及多会话之间的状态隔离。

工程上会把记忆拆成三层：

• 短期记忆：当前任务的上下文窗口，要控制预算。模型读到的每一步输入，都得经过裁剪。
• 会话记忆：一个用户/一次任务的持久化记录，存结构化存储，任务中断后可以恢复。
• 长期记忆：跨会话的知识沉淀，比如用户偏好、项目背景、历史决策，通常用向量库或知识图谱。

三层记忆的读写策略完全不同。个人工具可以把“记忆”实现成一个全局字典，反正只有一个用户；生产环境这么做就是事故现场。我踩过这个坑：一开始图省事，把记忆存成全局变量，多用户一进来，互相串数据，A 用户的任务上下文里出现了 B 用户的文件路径，排查了半天才发现是内存共享导致的。从此以后，所有会话记忆都带上租户 ID 和任务 ID，并且强制序列化落库。

长期记忆还要考虑版本化：模型在某个时间点看到的上下文是一份快照，不能被并发任务改来改去。实现上可以用不可变的事件日志来记录记忆变更，而不是直接覆盖。

3.2 Skill 不是“写个 prompt”，是带 schema 的协议

“agent skill”这两年特别热，但很多人理解的 Skill 是错的，以为就是给模型一段更详细的指令，教它“你会什么”。真正的 Skill 是一份机器可读的协议，至少要包含这么几部分：

• 元数据：名称、一句话描述、适用触发条件
• 参数 Schema：调用这个 Skill 需要哪些字段，每个字段的类型和校验规则
• 指令与工作流：Skill 内部的多步操作怎么执行
• 资源绑定：Skill 依赖的知识库、模板、外部服务
• 退出与异常处理：失败时怎么返回，哪些情况要终止

为什么 Schema 最重要？因为模型的输出天生不稳定，它可能把参数名记错、把日期格式写错、把必填字段漏掉。有了精确的 Schema 和校验器，模型再怎么瞎编，到了网关这一层都会被拦下来。这就叫“不要相信模型的自觉，要相信接口的约束”。

在生产环境里，Skill 还要做版本管理。模型引用一个 Skill，应该像调用一个 API 一样，明确版本号；Skill 更新时，正在运行的任务不能静默切换版本，否则行为前后不一致，出问题根本没法追。这跟普通后端服务上线接口要向后兼容是一个道理。

3.3 Token 不是玄学，是预算和成本工程

热词里有人问“ai agent token 是什么意思”。简单说，token 是模型计费和处理文本的最小单位。但对生产 Agent 来说，token 更重要的含义是：成本上限、时延上限、能力的边界。

一个 Agent 任务一般要跑十几步甚至几十步，每一步都是一次完整的大模型调用。假设一次任务 20 步，每步平均 2000 token，那就是 4 万 token，是单次问答的 20 倍。如果不做预算，一个失控的循环可能在几分钟内烧掉你一个月的 API 预算。

工程上一般会做三件事：

1. 给每步设置 max_tokens，给整个任务设置总 token 预算，超了就强制进入降级流程。
2. 上下文动态压缩：超过阈值就摘要、检索、裁剪，而不是无脑全塞进窗口。
3. 按用户/任务维度做配额，防止单个调用方拖垮整个系统。

Token 预算还有一个隐藏用途：它是 Agent“反常行为”的早期告警信号。正常情况下一个任务消耗有大致范围，如果某次任务 token 消耗突然暴涨，大概率是 Agent 陷入了重复循环，这时候预算拦截比任何日志都管用。

4. 并发与可靠性：为什么你的 Agent 一上生产就崩

热词里“ai agent 怎么扛并发”问得很真实。我自己第一次把 Agent 部署到线上时，也经历了“单机跑得好好的，一上服务就崩”的经典过程。这里把关键拆开讲，你会发现并发问题根本不是“多线程”两个字能解决的。

4.1 扛并发不是加线程，是队列、工作池和限流的组合

个人工具的“并发”通常是 asyncio 或多线程，同时跑几个任务就完事了。生产 Agent 的难点在于，每个任务的时长极其不确定——一步可能 3 秒，也可能 3 分钟，一个任务可能 5 步结束，也可能 50 步还在继续。

所以正确做法是：任务队列 + 工作池 + 有界并发。

• 任务队列：用户提交的是一个“任务”，而不是一个“请求”。队列负责排队、优先级、持久化。
• 工作池：固定数量的 Worker 从队列里取任务，每个 Worker 同一时间只跑一个 Agent 实例。
• 有界并发：给并发量设上限，防止批量任务到达时把模型 API 的配额直接打爆。

这里有个关键点：队列必须是持久化的，不能只放内存。任务跑了一半进程重启，队列要从磁盘恢复，任务才能从断点继续。数据库表、消息队列都行，但一定不能在内存里裸奔。

并发上限怎么定？我一般按模型供应商的速率限制倒推。比如供应商给了每分钟 600 次调用、每分钟 10 万 token，那就把 Worker 数和每个任务的 token 预算做组合估算，再留 30% 的余量。别想着把额度打满，打满的结果就是批量任务全部进入限流重试，最后所有任务一起堆死。

4.2 幂等、超时与重试：LLM 世界里的生存法则

LLM 调用是最不可靠的依赖：延迟抖动大、随机失败多、偶尔输出一半就断了。个人工具遇到失败，你手动重跑一遍就行。生产 Agent 必须设计容错机制。

第一是超时。要给单次模型调用设置超时，而且要把“首 token 延迟”和“总完成时间”分开。流式输出时，首 token 可能很快，但总完成时间很长，超时设置不能一刀切。

第二是重试。LLM 的错误分两种：可重试的（限流、瞬时网络错误）和不可重试的（凭证失效、请求参数非法）。重试必须用指数退避，否则批量任务一重试，限流会被重新打得更死。

第三是幂等。这是最容易忽略的。一个 Agent 任务里，同一个工具调用可能因为网络问题被重发了，如果这个工具不是幂等的——比如创建订单、发送邮件、扣减库存——就会产生重复副作用。生产级的工具网关，要给工具加上幂等键：同一个动作 ID 只允许执行一次。老实说，这个在个人工具阶段几乎没人会想，但它恰恰是“生产”和“玩具”的分界线。

还有一个很多人踩过的坑：Agent 的循环没有 max_iterations。模型在某件事上反复打转，每转一圈消耗一次调用，永远不退出。个人工具里你看到它转两圈就停了；生产环境你不加限制，它能转到 API 余额归零。

4.3 可观测性：从看 print 到看全链路

个人工具排错靠 print，生产 Agent 排错靠 trace。我自己的经验是：Agent 一旦复杂起来，你根本不知道它内部经历了什么。唯一的办法，是把每一次“决策—行动—观察”都记录下来，串成一条链路。

需要记录至少这些内容：

• 每步的输入：模型看到了什么上下文，做了哪个决策
• 每次工具调用：参数是什么，返回了什么，花了多久
• 每段模型输出：原始输出、结构化解析结果
• 每个异常：重试了几次，最终成功还是失败

指标层面，重点看这几个：任务成功率、任务平均耗时、token 消耗、工具失败率、队列积压深度。有了这些，你才能在 Agent 又“莫名抽风”的时候，不用靠猜。

5. 安全边界：Agent 越能干，越需要缰绳

热词里“agent 安全”出现的频率也在涨。很多人以为 Agent 安全就是防 prompt 注入，其实这只是最外面一层。生产 Agent 的安全，本质上是在回答一个问题：一个能自主行动的软件，凭什么相信它不会越界？

5.1 权限收敛：给 Agent 最小够用的权限

个人工具跑在本地，权限等于你自己的权限，无所谓。生产 Agent 跑在服务器上，它的权限直接等于系统权限。所以第一条原则：给 Agent 的权限，永远小于等于它完成任务所需的最小权限。

具体怎么做：

• 文件系统：Agent 只能访问指定工作目录，不能扫盘，不能读环境变量文件。
• 网络出口：按域名/IP 做白名单，不能任意外联。
• 工具权限：每个工具单独授权，按用户/角色细分。普通用户触发的 Agent，不应该有调用“删除全库”工具的权限。

我之前在项目里吃过权限过大的亏。Agent 接到一个“整理文档”的任务，模型不知道哪根筋搭错了，直接去读系统里的环境变量文件，还想把内容打包发出去。如果没有文件系统隔离和网络出口白名单，这就是一次真实事故，而不是一次“有趣的行为”。

5.2 凭证管理和数据隔离

生产 Agent 要调用各种外部服务的 API，这些密钥不能出现在 prompt 里，也不能明文写在配置里。正确做法是：用密钥管理服务统一管理，在工具网关这层做注入。模型根本不接触真正的密钥，它只拿到一个短期令牌。

数据隔离同样重要。如果你的 Agent 是多用户可用的，那每个用户看到的上下文、能访问的数据，都必须按租户隔离。尤其当 Agent 会调用 RAG 检索知识库时，“把 A 用户的数据检索出来喂给了 B 用户”是最可怕的一类错误。这需要在检索层就限定数据范围，而不是寄希望于模型“不乱说”。

这里还有一个细节：工具调用返回的数据，落日志之前要做脱敏。不然 trace 日志本身会成为新的数据泄露口。

5.3 沙箱、人工审核与逃生舱

再强的规则也有漏网的时候，所以还要给执行环境加物理边界：

• 沙箱：Agent 的代码执行、浏览器操作，尽量放进容器或虚拟机。跑完销毁，不留残余。
• 人工审核：对高风险动作，比如对外发消息、删除数据、下单付款，必须设置人工确认环节。现在的 Agent 框架里已经普遍有这个设计了，但你得主动把它打开。
• 逃生舱：一键停止所有 Agent、回滚到上一个稳定快照、强制终止异常会话。这个不是可选项，是生产 Agent 的标配。

记住一个判断标准：如果一个 Agent 的行为你无法在五分钟之内强制终止并还原，那它就不具备上生产的资格。

6. 框架选型与落地路径：从踩坑到自研 harness

最后聊框架。热词里“agent 框架如 langchain、dify、crewai 等，哪个好”是高频问题。我把自己的选型思路写出来，不一定适合所有团队，但方向是通用的。

6.1 主流框架到底各自解决了什么

先放一张对比表：

我的个人观点：个人工具阶段，选哪个都行，顺手的就好。生产 Agent 阶段，选型不看“哪个框架功能多”，而是看四件事：可观测性好不好、可测试性强不强、失败可恢复性有没有、权限模型能不能按你的需求收紧。满足不了的，就得考虑在框架之上做自己的 harness，或者干脆自研。

现在市面上也冒出了不少把 harness 作为产品来做的 Agent 工作台和第三方控制台，思路和前面聊的 2.3 节一样：把编排层、技能层、记忆层做成标准能力，让开发者不用从零写 harness。这些方案对中小团队很友好，但要留意它们能不能对接你的私有数据、能不能满足你的权限模型，别只图省事。

6.2 什么时候应该放弃框架

框架给你节省了搭建时间，但它也替你做了很多隐式决策。在生产环境，这些“隐式决策”最要命。举个例子：某个框架自带的模型重试逻辑，在限流时会自动等待重试，这在低并发时很贴心，但在高并发时，会让所有任务同步阻塞，把一次小故障放大成一个梯队。框架不会告诉你这些，你只有在事故复盘时才会发现。

遇到下面这些情况，我会强烈建议自己控制 harness：

1. 你需要自定义并发模型，比如按租户隔离的队列。
2. 你的工具调用链涉及强安全要求，框架的权限模型覆盖不了。
3. 你需要精细控制 token 成本和重试策略，框架给不了这种粒度。
4. 你需要在每一步插入自定义审计逻辑。

说到底，框架是个起点，不是终点。真正负责的人，会在框架外面再包一层自己的 harness。

6.3 从个人工具升级生产 Agent 的可落地路径

如果你想把手上的个人工具往生产推，不用一步到位，按下面顺序改造就行：

1. 加状态持久化：任务状态从内存移到数据库，进程重启不丢任务。
2. 加边界：max_iterations、单步超时、总 token 预算，把失控循环扼杀掉。
3. 加工具网关：统一入口，校验参数，记录调用日志。
4. 加权限：每个工具按最小权限授权，按用户/租户隔离数据。
5. 加队列和限流：把同步调用改成“任务入队 + Worker 消费”，控制并发上限。
6. 加可观测性：把每一步决策、每次工具调用串成 trace。
7. 加入工审核：高风险动作必须人工确认。

每一步做完，系统就往“生产级”挪了一点。不用追求一天全做完，但方向要对。

如果只让我留一个判断标准，我会这么说：个人工具的核心是“帮我把这件事干完”，生产 Agent 的核心是“替我把这件事持续、安全、可被追责地干完”。从前者到后者，不是换个更大的模型、加个并发这么简单，而是要把“模型万一蠢了怎么办、坏了怎么发现、越界了怎么拦住”这些问题，都当成一等公民去设计。

我自己在这条路上也翻过不少车。最早那个裸奔的 while 循环，到现在还留着，每次想加什么新功能，都会拿它跑一遍实验，但已经不会再让它靠近生产环境半步。工具本来就是用来干活和试错的；生产，是用来守住承诺的。