企业官网建设流程全解析

我第一个正儿八经做的 agent 管理项目，其实算不上多么宏大——没有上百个 agent 协同作战的壮观场面，也没有跑在几十台机器上的分布式调度。就是几个不同职责的 agent，要一起完成一个涉及检索、分析、生成、核查的自动化工作流。但就是这“几个”，差点把我整崩溃。

单 agent 开发的时候，你只需要关心提示词和工具调用，出了问题翻日志很快能定位。一旦变成多个 agent 协作，事情就完全不同了：谁先跑、谁后跑、A 的结果怎么传给 B、B 中途挂了 A 要不要重跑、两个 agent 同时调用同一个工具会不会冲突、跑了几轮之后 agent 是否还记得最初的目标——这些乱七八糟的问题全冒出来了。用一句话概括就是：从“怎么让一个 agent 干活”变成了“怎么管好一群 agent 干活”，后者的难度是数量级的提升。

这篇内容就是把我这轮“初尝试”的完整过程做个复盘，包括我踩过的坑、换过的思路、最终落地的方案，以及一整套目前还在用的管理框架雏形。如果你也正在从单 agent 往多 agent 方向走，或者已经在为 agent 失控头痛，这篇内容应该能给你省下不少时间。

1. 先搞明白：agent 管理到底在管什么

1.1 单 agent 时代根本不需要“管理”

很多人对“agent 管理”的理解是模糊的，我一开始也是。先梳理一下：你写一个 agent，给它一个系统提示词，挂上几个工具函数，然后让它去查资料、写报告、总结邮件。这种情况下，你基本不需要什么管理框架——一个循环加一个 promise 就结束了，agent 从头到尾只有一个任务线，状态异常简单，出错了大不了重新跑一次。

但当你开始拆分成多个 agent 的时候，麻烦就来了。我的项目里拆分出了四类角色：一个负责检索信息的 research agent，一个负责内容生成的 writing agent，一个负责事实核查的 reviewer agent，还有一个负责汇总的 coordinator agent。它们不是串行执行的，中间有交叉——research 跑几步就要把半成品交给 writing，writing 写完了要等 reviewer 的反馈才能定稿，coordinator 又要实时了解所有人的进度。

这时候你就会发现，agent 本身没有“职业素养”——它们不会主动告诉你自己卡在哪了，不会在你没要求的时候停下来等你，更不会自觉地从上一次失败中吸取教训。没有管理层的多 agent 系统，本质上是把一堆不可控的代码丢进了生产环境。

1.2 管理要覆盖六个维度

把我这轮折腾下来摸到的边界整理一下，agent 管理至少要覆盖六个维度，缺一个后面都会出问题。

状态管理是最基础的一层。每个 agent 在任意时刻必须有一个明确的状态：idle、running、suspended、completed、failed。不然你没法回答最核心的问题——“现在系统跑到哪一步了”。我第一版没做这层，全靠人肉翻日志，结果就是每次出问题都要把所有 agent 的上下文从头读一遍，极其痛苦。

生命周期管理关心的是“活着”的问题。agent 进程什么时候启动、什么时候该被销毁、内存泄漏了怎么处理、崩溃了怎么拉起。在本地实验的时候这个还好说，真到了生产环境，一个 agent 挂掉导致整条链路阻塞，如果没有 watchdog 机制，你就等着被用户投诉吧。

任务编排管理是核心中的核心。多个 agent 之间谁先谁后、哪些可以并行、哪些必须串行、一个 agent 的输出要经过什么转换才能成为另一个 agent 的输入，这些都需要一个明确的编排层。我最初试图把所有逻辑都写在主脚本里，后来发现那样写出来的代码就是一团意大利面，改了这边那边就崩。

记忆与上下文管理是 agent 能不能“记得住事”的关键。每个 agent 都有自己的上下文窗口，但多 agent 协作中，信息需要跨 agent 传递。一个 agent 产生的重要结论怎么沉淀下来，让其他 agent 在需要的时候能访问到，这就是记忆系统要解决的。不做这层，你会发现每个 agent 都在“失忆”，同一个错误反复犯。

安全与权限管理管的是“能做什么”的边界。不是所有 agent 都应该有权限调用所有工具。我的检索 agent 只需要读权限，审核 agent 只需要对比权限，只有 coordinator 才有权利发起最终的写操作。如果不做隔离，一个 agent 的越权行为就可能搞乱整个系统的数据。

可观测性管理让一切变得可追踪。每个 agent 的输入输出、token 消耗、工具调用记录都要能查出来。多 agent 系统是个典型的分布式问题，没有完善的日志和追踪机制，出了问题你根本不知道是哪个环节的锅。

1.3 管理不需要一步到位

这里要先给读这篇文章的朋友泼一盆冷水：我上面说的六个维度，不是一个周末能全做完的。我的实际路径是先做状态管理和任务编排，这两个是骨架，不做系统根本跑不起来。记忆系统是第二优先级，因为多 agent 协作一旦超过十几个来回，没有记忆简直就是灾难。安全与可观测性我是一边跑一边补的，先让系统能工作起来，再逐步加上监控和限制。

这个优先级顺序，我觉得对大多数从零开始做 agent 管理的人是适用的。别一开始就想着建一个完美的大厦，先把毛坯房搭起来能住人，后面再慢慢精装修。

2. 方案选型：托管框架还是自研 harness

2.1 市面上的框架先试了一圈

说到 agent 管理，绕不开的问题就是用不用现成框架。我前后试了几个主流方案，包括 Microsoft Agent Framework、LangGraph，还有一些偏轻量的开源项目，简单说说我的感受。

Microsoft Agent Framework的野心很大，它试图做一个完整的 agent 生态，从客户端交互到云服务托管都有对应的方案。它的特色是把 agent 的创建、管理、调用都标准化的思路，适合团队协作场景。但我个人体感是它在多 agent 编排上还不够流畅，有些概念绕来绕去，学习成本不低。而且它对于本地小规模场景有点杀鸡用牛刀。

LangGraph是我目前最推荐的现成方案。它把 agent 的流程建模成一张图，节点是各种操作，边是状态转移，这天然就是 agent 管理要的核心能力。LangGraph 内置了持久化层，可以保存每个节点的状态，还支持 checkpoint 机制——也就是说，agent 跑到一半崩溃了，可以从最近的 checkpoint 恢复，不用从头再来。这一点在长任务里价值太大了。它的条件分支和并行分支也很好用，能比较优雅地处理多个 agent 之间的复杂关系。

轻量开源方案我也试过几个，比如一些做任务编排的微框架，但说实话，这些大多只解决了“并发调用”的问题，对 agent 特有的状态管理、记忆管理支持很弱。当你的 agent 开始出现“需要记住上一轮结论才能继续当前任务”的时候，光有并发框架是不够的。

我的结论是：如果你的项目规模不大，但确实需要多 agent 协作，优先考虑 LangGraph；如果你有很强的自研能力和独特需求，再考虑从零写 harness。我最终走的是混合路线——用 LangGraph 做编排底层，自己在上面封装了一层管理逻辑，这样既有框架的稳定性，又有足够的灵活性。

2.2 理解 harness、skill 与 agent 的关系

这个圈子里概念很多，而且各家定义还不完全一致，很容易把人绕晕。我用自己的话梳理一下，方便大家理解我后续的设计。

Agent是逻辑上的智能体，它有目标、有推理能力、有工具调用能力。你说“帮我写一份市场分析报告”，一个 agent 会拆解成“搜索资料、整理数据、生成报告文案”等多个步骤——但注意，同一个人设的 agent 干了这三件事，不代表它需要被拆成三个 agent。

Harness是包裹在 agent 外部的运行时环境。它不是 agent 本身，而是让 agent 能跑起来的“基础设施”——包括输入输出接口、工具注册中心、错误处理机制、上下文管理、安全沙箱等。可以理解成：agent 是内核，harness 是操作系统。你为什么要区分这两者？因为同一个 agent（内核）可能会被部署在不同的 harness 里——开发环境一个版本、生产环境一个版本，只要 harness 提供的接口一致，agent 本身不需要重新开发。

Skill则是 agent 可以“调用”的能力单元，或者说是一套预定义的操作流程。比如说“文件上传 skill”、“数据库查询 skill”。Skill 的一个重要特性是可复用——不同 agent 可以共享同一个 skill，就像不同程序可以调用同一个标准库函数。它和 agent 的关系是：agent 决定什么时候调用 skill，skill 负责具体怎么执行。

理解这三者的关系能让管理方案清晰很多：被管理的核心对象是 agent，agent 运行在 harness 之上，通过 skill 来执行具体操作。我的管理架构里，harness 层处理状态和生命周期，skill 层处理权限和调用边界，agent 层只负责业务逻辑。每一层改起来都不太会影响其他层。

2.3 为什么我没有完全自研

其实一开始我倾向于完全自研一套 harness，因为市面上没有完全契合我需求的方案。但后来想通了，自研的代价太高了——不只是开发时间，还有后续的维护成本。拿上下文管理来说，看起来简单，实际要做的事情非常多：token 计数、滑动窗口裁剪、关键信息提取和归档、跨上下文传递等——这些通用能力，框架已经做得很成熟了，你没有必要重新发明轮子。

自研的意义在于解决框架覆盖不到的领域特性问题，而不是把通用能力重做一遍。我的经验是：先站在框架的肩膀上把系统跑起来，再往深处挖自己的差异化能力。这比从零开始风险低得多，而且能更快看到效果。

3. 第一版 agent 管理实践的完整落地过程

3.1 系统架构：我最终怎么搭的

如果你要自己搭建 agent 管理，我建议先画一个架构图（在脑子里或者在纸上都行）。我的最终架构是这样的：

• 编排层：主控程序，基于 LangGraph 构建，负责任务的拆解、路由、状态转移。这是整个系统的大脑，决定哪一步该由谁执行。
• 执行层：具体的 agent 实例。每个 agent 有独立的生命周期，运行在统一的 harness 环境中，通过 skill 调用外部工具。
• 记忆层：采用双层记忆结构。短期记忆存在 Redis 里，保存当前任务上下文的临时信息，TTL 设置成 30 分钟；长期记忆存在 SQLite 里，保存跨任务的关键结论，供未来的新任务参考。
• 状态存储层：用 SQLite 记录所有 agent 的状态流转历史，支持回溯。
• 监控层：把 agent 的关键事件（启动、成功、失败、Token 消耗）写入结构化日志，便于分析和排查。

这个架构看起来简单，但是跑起来的稳定性比我第一版（纯脚本硬编码）好了不知道多少。

3.2 Agent 状态机的设计和实现

状态机是整个管理系统的地基。我设计了六个状态，覆盖 agent 从创建到销毁的完整生命周期：

实现上非常简单，用 SQLite 存状态，每个 agent 启动时插入一条记录，状态变更就 UPDATE。为了防止并发问题，每次更新都用带条件的事务（比如只有当前状态是 RUNNING 才能改成 COMPLETED）。

实际跑下来发现，最重要也是最容易忽略的是SUSPENDED 状态。一开始我没有这个状态，结果就是当某个 agent 的 token 消耗超过阈值时，我只能眼睁睁看着它继续烧钱。加了 SUSPENDED 之后，一旦检测到异常，立刻把 agent 挂起，人工审核后再决定恢复还是终止。这个机制帮我省了不少钱。

3.3 任务编排：状态图还是直接代码

LangGraph 的编排方式是基于状态图的——定义好节点和边，框架负责执行。节点是函数（或者说是封装了 agent 调用的函数），边是条件判断。举个例子，我的工作流是：

from langgraph.graph import StateGraph, END class AgentState(TypedDict): topic: str drafts: list review_result: dict final_output: str def research_node(state: AgentState): # 调用 research agent results = research_agent.run(state["topic"]) return {"drafts": results} def writing_node(state: AgentState): # 调用 writing agent 基于检索结果生成草稿 draft = writing_agent.run(state["drafts"]) return {"drafts": state["drafts"] + [draft]} def review_node(state: AgentState): # 调用 reviewer agent 审查草稿 result = reviewer_agent.run(state["drafts"][-1]) return {"review_result": result} def should_continue(state: AgentState): # 审查通过则结束，否则回到写作节点重写 if state["review_result"].get("passed"): return "end" return "rewrite" graph = StateGraph(AgentState) graph.add_node("research", research_node) graph.add_node("writing", writing_node) graph.add_node("review", review_node) graph.set_entry_point("research") graph.add_edge("research", "writing") graph.add_edge("writing", "review") graph.add_conditional_edges( "review", should_continue, {"end": END, "rewrite": "writing"} )

这个模式的优雅之处在于，每个节点都是纯函数——输入一个状态，输出一个新的状态。框架替你把状态在节点间传递的脏活累活做了，还自动保存了每一步的状态快照。我可以随时把整条执行链回放一遍，看每一步的输出是什么，这比定位普通脚本故障容易太多了。

3.4 记忆与上下文的落地处理

记忆这块踩的坑最多。最先遇到的问题就是：上下文越跑越大，token 消耗越来越夸张。单个 agent 对话轮数多了以后，系统提示词加历史对话加工具返回，很容易就撞上上下文窗口上限。

我的解决方案是三层处理：

第一层，压缩。每轮对话结束后，把历史消息里的工具返回结果做摘要替换。比如一个搜索操作返回了 5000 字的网页内容，我把它压缩成“搜索获取到 5 条结果，其中第 3 条提到……”，这样能省掉大量空间。

第二层，归档。判断历史消息的重要程度，超过一定轮数且不再被引用的内容，移入长期记忆库。归档后的内容不在当前上下文中，但如果 agent 需要，可以主动查询检索。

第三层，结构化存储。业务上的关键结论，格式化成结构化数据存到数据库里，而不是藏在对话历史里。比如审查结论，保存成{agent_id: "reviewer_01", decision: "fail", reason: "数据来源不可靠"}，即使对话早被清理了，关键信息依然在。

这样的设计让记忆系统有了“分层”——热点数据在上下文中，非热点数据在存储中，需要时可以召回。用这个结构，我的系统在跑十几个小时的长任务时，上下文窗口一直稳定在 12k token 以内。

3.5 安全：权限隔离和审计

多 agent 场景下的安全问题，比单 agent 复杂得多。核心问题是：你没法确定哪一个 agent 的哪一句自由发挥会产生不可预期的后果。

我做了两层防护。第一层是工具权限隔离。给每个 skill 打标签，给每个 agent 配置可调用标签集合，运行时校验。比如：

SKILL_REGISTRY = { "web_search": {"tags": ["read"], "func": search_web}, "db_write": {"tags": ["write"], "func": write_database}, "file_upload": {"tags": ["write"], "func": upload_file}, } AGENT_PERMISSIONS = { "research_agent": {"allowed_tags": ["read"]}, "writer_agent": {"allowed_tags": ["read"]}, "coordinator_agent": {"allowed_tags": ["read", "write"]}, }

执行 skill 之前先检查权限，无权调用直接拒绝并记录日志。这套机制让我那个只有只读权限的检索 agent 永远不可能去写数据库，即使它被提示词注入攻击了，损失也在可控范围内。

第二层是完整的审计追踪。每次 agent 调用工具、读取记忆、生成内容，都会追加一条审计记录，包含时间戳、agent ID、操作内容、token 消耗量。这个审计日志平时不怎么看，但一旦出了问题，它就是破案的关键线索。有一次一个 agent 重复执行了一个搜索操作七八次，就是因为审计日志里发现了 token 消耗异常才定位到的。

3.6 可观测性：结构化日志和服务健康检查

普通单 agent 的开发调试，print 大法足够。但多个 agent 并行跑的时候，print 出来的日志交错在一起，根本没法看。我最终做了两件小事，解决效果立竿见影：

第一，全部改成结构化日志，每条日志是一个 JSON 对象，包含字段：timestamp、agent_id、event_type、status、detail、token_usage。这样可以用 jq 命令轻松过滤和分析，不用人肉从一段混乱文本里捞线索。

jq 'select(.agent_id=="writer_agent")' agent.log

第二，实现了一个简单的健康检查接口。每 10 秒扫描一次所有 agent 的状态，如果发现某个 agent 卡在 RUNNING 状态超过 15 分钟没有更新，就自动触发 SUSPENDED，并推送告警。这个机制针对的就是 LLM 调用时不时会出现长时间无响应的场景——应用层超时如果没设好，一个卡死的请求能让整个工作流停摆。

4. 避坑指南：那些百度不到的问题

4.1 “Agent execution terminated due to error” 到底怎么排查

这是我在搜索热词里看到的高频问题，自己实际也碰到过。这个报错很让人抓狂，因为它非常笼统，没告诉你是哪一步出了问题。根据我这几个月的经验，遇到这个报错按以下顺序排查，效率最高：

第一步，检查日志里有没有详细的堆栈信息或错误码。很多框架会把这个扩展信息打印在紧邻的日志行里，只是隔了几层封装，不仔细看日志会漏掉。直接搜 FATAL、ERROR 级别的日志，不要只盯着最后一行。

第二步，检查上下文的超长或截断问题。上下文超出模型最大限制时，很多框架的默认处理就是直接终止执行，报一个笼统的 error。这种问题的特征是随机性——一会儿跑得通一会儿跑不通，并且任务越长越容易出问题。我的策略是把输入消息做个字数统计，超过阈值先做压缩再提交。

第三步，检查工具调用链。如果一个 agent 调用了另一个工具，而工具本身在运行过程中抛了异常，这个异常在往上层传递时经常会被框架吞噬成“agent execution terminated due to error”。解决办法是在工具函数的入口和出口各加一条日志，这样至少能定位到具体是哪个工具出的问题。

第四步，检查并发冲突。多个 agent 同时修改同一个共享状态或者缓存时，可能会触发底层的数据竞争，导致执行被终止。我遇到过一次两个 agent 同时向同一个 SQLite 文件写入导致数据库锁异常的情况，改动完成——把所有写操作改成了串行队列。

4.2 并行 agent 的数据冲突问题

说到并发冲突，这是一个多 agent 系统绕不过去的坎。最常见的问题是：两个 agent 同时读取同一个输入数据，各自处理完后把结果写回同一个数据表，后写的一方覆盖了先写的结果。

解决这个问题的标准方法是版本控制。每条数据记录加一个版本号，写入的时候校验版本号是否与读取时一致，不一致就说明数据被其他 agent 改过了，需要重新读取再合并。如果你用的是 SQLite，可以用一个简单的UPDATE ... WHERE version = ?语句实现乐观锁：

UPDATE agent_results SET result = ?, version = version + 1 WHERE task_id = ? AND version = ?;

受影响行数为 0 时，说明版本冲突了，业务层做重试。这个方法实现成本低，实测在十几个 agent 并行跑的场景下，冲突率不高，但一旦冲突就能被及时捕获，不会再出现静默覆盖的问题。

另一个避坑经验：不要把共享状态放在内存里。一开始我用的是一个全局字典对象来存储各个 agent 的产出，结果 Python 的多线程一跑起来，各种怪问题层出不穷。后来全部改成数据库存储，每次读写都走 DB，虽然性能上慢一点，但稳定性提升明显。多 agent 系统，正确的做法是让 agent 之间尽量无状态，唯一的状态存在共享存储层。

4.3 可控性优先：大模型输出的不确定性管理

多 agent 系统最大的敌人，不是代码逻辑 bug，而是 LLM 的输出不确定性。同一个输入，同一个 agent，跑五次可能有五种不同的结果。在管理层面，这意味着你要假设 agent 的输出是“不可靠的”，并且在流程设计上做防护。

我的做法是把 agent 的输出做一层结构化校验。所有 agent 在返回结果时，强制要求输出一个 JSON 对象，包含status、result、reason三个字段。框架层拿到这个 JSON 后，会做 schema 校验，校验不通过就自动触发一次重试，并附带错误信息让 agent 自我修正。这相当于给 LLM 加了一道“语法检查”，能拦截大部分格式不规范的问题。

另外，关键节点必须有确定性兜底方案。比如审查 agent 给了一个“fail”结果，系统不能直接重启整个流程就完了，而是要把 fail 的原因记录下来、和之前的尝试次数做比较——如果连续失败超过三次，就转人工。把人为干预的入口留在系统里，这在实际运行中非常重要。不要试图让 agent 完全自治，至少在现阶段，关键决策的最终控制权要留在人手里。

4.4 Token 成本失控的实时监控

多 agent 系统的 token 消耗，比单 agent 场景更容易失控。单个 agent 跑一次对话可能只消耗几千 token，但多个 agent 并行、加上重试机制、加上上下文越滚越大，一天下来账单可能是你预期的三到五倍。

我做的监控很简单：写了一个后台循环，每隔一分钟读一次 token 用量的统计表，计算每分钟的 token 消耗速率。如果速率超过设定阈值，就把相关 agent 挂起并推送通知。阈值怎么设置？我建议先跑几天正常任务，拿到正常消耗的基线数据，然后设置成基线的 1.5 倍作为告警阈值，2 倍作为强制挂起阈值。

另外一个实用的省钱技巧是重试时削减上下文。LLM 推理失败重试，不一定要把完整的历史上下文重新发给模型。很多时候，错误只和最后几轮对话相关，把前面的历史压缩掉，只保留关键结论和最近一轮的完整信息，重试的成功率不会低，但 token 消耗能降一半以上。

5. 这套管理方案后续还能往哪里扩展

5.1 从“管理 agent”到“管理 agent 集群”

目前这套方案管的是进程级别或者逻辑级别的 agent，每个 agent 跑在自己的运行时里，用共享数据库通信。如果未来 agent 数量上来——比如超过五十个——这套方案的瓶颈就会暴露出来：SQLite 顶不住高并发的写入，单机的资源上限也会卡住你的扩展。

到时候的方向有两个：一是引入真正的消息队列（比如 RabbitMQ 或 Kafka）来替代现在的数据库通信，让 agent 之间的消息传递异步化、解耦；二是把 agent 的执行放到 Kubernetes 集群里，每个 agent 对应一个 pod，用 K8s 原生的生命周期管理来替代部分自研的 watchdog 逻辑。这两个方向都需要不少架构改造，但对于支撑真正的生产级 agent 平台来说，可能是绕不开的路。

5.2 从“单次任务编排”到“持续自主运行”

现在我的系统还是“接到任务 -> 执行 -> 返回结果 -> 结束”的模式，属于被动运营。但 agent 真正的潜力在于主动运行——它会自己发现问题、自己拆解任务、自己执行、自己复盘改进。这需要管理框架增加两块能力：一是目标驱动的行为管理，agent 不仅仅是执行任务，还要围绕长期目标自我规划和调整；二是元认知评估，agent 要能评估自己的执行效果，然后决定是否需要调整策略。

这些能力在 OpenAI 后来的 coding agent 以及一些社区项目里已经初见雏形，但要落地到生产环境还早。目前的 agent 管理框架，更多还是围绕“流程稳定跑完”来设计的，距离“让 agent 自我进化”还有不少距离。

5.3 从“单体管理”到“联邦管理”

最后想聊一个更远的方向：跨系统的 agent 相互调用。目前各家 agent 平台的 dismiss 标准不统一，Agent A 在平台甲上、Agent B 在平台乙上，它们之间没法直接通信和协作。未来如果出现一个通用的 agent 身份协议和通信协议，管理框架就需要支持“联邦管理”——能对接外部 agent、统一身份验证、统一权限管理。这有点像早期社交平台的开放 API 演进，需要生态层面的推动。作为从业者，我现在至少会在代码层面保持接口的抽象性，为将来接外部 agent 留好扩展位。

6. 最后聊点实在的

做了这轮 agent 管理初尝试，我最深的体会是：agent 管理不是某一个单一技术点，而是一整套思维方式的转变。从“写一个聪明的 prompt”到“设计一套可管理的系统”，中间隔着的不是代码量，而是对不确定性、故障、成本和边界的理解。

如果你现在正准备自己做 agent 管理，我的建议是：先把状态机和任务编排做扎实，这是地基；然后尽快加上审计日志和成本监控，这能让你在出问题时不至于裸奔；至于记忆系统和安全管理，可以边跑边补，不用一步到位。

再分享一个小小的实操技巧：在你自己的 agent 管理架构里，为每个 agent 加上一个description字段，记录这个 agent 的职责、擅长场景、常用工具。当 agent 数量多起来之后，你会发现这行字在排查问题、优化分工的时候有多好用——它能让任何一个人（包括两周后的你自己）在打开代码的时候，快速理解每个 agent 是干什么的。

agent 管理这条路还很长，我这套方案也远谈不上完美。但至少现在，几个 agent 一起干活的时候，我心里是有底的。希望这篇内容也能让你心里有底。