企业官网建设流程全解析

作为团队里最早折腾 Agent 的那批人，我一度以为 AI 编程助手的尽头是个人定制。直到我们公司把分散在各处的脚本、提示词、API 密钥攒成一个共享的 Every Agent，我才意识到：个人化 Agent 的舒适区，恰恰是团队效率的黑洞。这篇内容就是复盘我们如何从“每人一个私货机器人”走向“全公司共用一个 Agent 平台”，以及背后的坑和取舍。

先说结论：Every Agent 不是简单地把某个机器人挂到公司群里让所有人 @ 它，而是基于 Claude Managed Agents 搭建的一套共享基础设施，把技能、上下文、权限和审计都收归平台统一管理。团队里有人拿它做周报摘要，有人让它跑数据接口，还有人给它接上了内部工单系统。我更愿意把它理解成公司的“AI 同事”，而不是“AI 工具”。

这篇文章适合谁看？如果你正在犹豫要不要在团队里推广 Agent，或者已经被“每人一个 Agent、互不兼容”的局面折腾到头大，那么这里面的架构拆解、落地细节和踩坑记录应该能帮你省下不少弯路。

1. 为什么非要做一个“全公司共享”的 Agent

1.1 个人化 Agent 的失控：本地脚本、临时提示词和私藏密钥

在 Every Agent 之前，我们团队的 Agent 使用方式基本处于“各自为战”阶段。有人把 Prompt 写在本地文本文件里，有人用浏览器插件凑合，还有人直接在聊天界面里反复粘贴同一段指令。最要命的是 API 密钥，几乎每个人都用自己的账号申请了一份额度，月底对账的时候财务差点以为有人刷单。

这种个人化 Agent 有两个隐性问题。一是没法沉淀，A 同学调好的工作流，B 同学完全不知道存在，过两个月 A 一离职，这套东西就跟着消失了。二是没法管控，你根本不知道同事的 Agent 每天在访问哪些接口、输出哪些内容，真要出了数据合规问题，追溯起来像大海捞针。

我最初也觉得 Agent 这种工具就该是“私人定制”，直到某天我发现隔壁同事用他的个人 Agent 在对接客户数据，而那个 Agent 的提示词里居然写着“忽略所有安全限制”。那一刻我明白，个人化不在问题是失控的必然结果，尤其是在团队规模超过十个人之后。

1.2 共享的实质不是“公用”，而是“基建复用”

很多人一听全公司共享 Agent，第一反应是“大家都用同一个机器人，那岂不是排队抢资源”。实际上共享 Agent 的价值在于把地基打好，让不同团队在上层各盖各的房子，而不是所有人挤在一间屋里。

我们内部把 Every Agent 定位成“Agent 基础设施”：统一了模型调用入口、统一了权限认证、统一了技能注册方式。业务团队不需要关心模型是怎么部署的、密钥放在哪里、限流策略怎么配，只需要关注自己那部分技能逻辑即可。这和公司里统一用一套代码仓库、一套 CI/CD 管线是一个道理。

这个定位想清楚之后，很多设计决策就顺了。比如权限模型，不能做成“所有人对 Agent 有同等访问权”，而要做成“Agent 的每个技能都声明自己需要什么权限，用户在调用时按需授权”。再比如技能管理，不能靠某个人往代码库里塞个文件就算上线，要有注册、审核、灰度、下线的完整流程。基建想清楚了，共享才不会变成混乱的放大镜。

1.3 为什么选 Claude Managed Agents 而不是自建编排框架

这个选择我们内部吵过好几轮。有同事主张直接用开源框架搭配大模型 API 自建，理由是灵活；也有人主张干脆让各团队各用各的，不做统一平台。最后选择 Claude Managed Agents，核心原因是它在“受管”这件事上做得比自建更省心。

Managed Agents 的意思是，模型调度、上下文管理、人机交互循环这些繁琐的部分都由平台托管。我们自己写的话，光是处理工具调用的循环、多轮对话的上下文裁剪、异常重试，就够一个小组忙活一个月。而且 Claude Managed Agents 支持声明式的 Agent 配置，技能、模型参数、系统提示词都能在配置文件里定义清楚，天然适合“代码即配置”的团队协作方式。

当然，自建方案的吸引力确实存在，比如可以接任意模型、可以深度定制交互界面。但对一个以业务交付为主的技术团队来说，追求“编排自由”的代价是承担全部运维复杂度。我们最后达成的共识是：先把可控的共享平台跑起来，如果未来确实需要深度定制再迁移也不迟。事实也证明，现阶段 Managed Agents 的能力边界足够覆盖公司内部九成以上的场景。

2. 整体架构拆解：共享层、管理层与应用层

2.1 三层模型的思考：不要把鸡蛋放在一个篮子里

Every Agent 的架构我们最后收敛成三层：共享层、管理层、应用层。共享层负责通用的能力，比如统一的模型网关、统一的知识库、统一的技能注册表；管理层负责治理，比如权限校验、审计日志、灰度发布、用量统计；应用层则是各个业务团队基于平台开发的具体技能和场景。

这个分层的灵感其实来自微服务架构里的“平台工程”思路。我们不想让每个团队都从零搭一套 Agent 环境，也不想让平台团队包办所有业务逻辑。共享层解决“重复造轮子”的问题，管理层解决“出了事找谁”的问题，应用层解决“业务怎么跑起来”的问题。

从实际操作来看，三层模型最大的好处是责任边界清晰。平台团队只管共享层和管理层的稳定性，业务团队只管应用层的逻辑，两边通过定义良好的接口协作，不容易互相甩锅。这个架构听起来没什么新奇，但在团队协作里，越朴素的边界划分越能减少沟通成本。

2.2 技能注册表：Agent 世界里最像“产品目录”的东西

技能注册表是整个共享 Agent 的核心。每个技能本质上是一个被封装好的能力单元，比如“查工单状态”“生成周报摘要”“调用数据分析接口”。技能在注册表里声明三样东西：输入参数、输出格式、所需权限。

设计技能注册表时我们参考了 OpenAPI 的思路。每个技能都有唯一的名称和版本号，调用方通过自然语言触发，由 Agent 决定调用哪个技能。技能之间不允许互相调用，这是为了避免出现“技能的技能”这种无限嵌套，否则审计链路会变得非常复杂。

注册表还承担了“技能市场”的角色。我们发现，团队里最受欢迎的技能往往来自意想不到的地方，比如有一个实习生写的“会议室空闲查询”技能，上线一周就被用了两百多次。技能一旦在注册表里沉淀下来，后续再有团队需要类似能力，直接搜索就能复用，不用重新发明轮子。

2.3 管理层：权限模型、审计日志与可观测性

管理层是 Every Agent 里最不性感性、但最救命的模块。权限模型我们最终采用了“技能级授权”：用户对 Agent 的访问是整体的，但 Agent 调用某个技能时，需要校验该用户是否具备对应权限。比如普通员工可以调“查自己工单”的技能，但只有主管能调“批量导出部门工单”的技能。

审计日志的设计也踩过坑。最初我们只记录“谁在什么时间问了 Agent 什么”，后来发现这远远不够——一旦涉及敏感数据，你需要知道 Agent 到底调了哪个技能、传了什么参数、模型返回了什么内容。所以审计日志的粒度细化到了“一次会话、N 次技能调用、每个技能的输入输出摘要”，虽然存储成本上去了，但安全性换回来了。

可观测性这块用了常规的指标：调用量、延迟、Token 消耗、错误率、技能失败分布。最有价值的是技能失败分布，通过它我们发现某个知识库检索技能经常在下午时段超时，后来排查出是索引没做增量更新。如果只盯着平均延迟看，这种问题说不定要过很久才能暴露。

2.4 应用层：各团队怎么基于共享平台开发自己的 Agent

应用层是业务团队的主场。我们的做法是提供一个“技能开发模板”，团队只要按照模板补充技能描述、输入输出 schema、调用逻辑和测试用例，就能把新技能注册到共享 Agent 里。平台团队审核通过后，技能自动进入灰度名单。

实际开发中，业务团队最大的困难不是写技能的调用逻辑，而是写清楚的“技能描述”。同一个技能，描述写得模棱两可，Agent 就不容易在合适的时机调用它。后来我们总结出一套描述规范：动作开头、明确输入条件、标注不适用场景。比如“当用户询问工单状态时，调用此技能获取最新进度；如果工单编号缺失，请先向用户索要”。

应用层的成熟度直接决定了 Every Agent 的可用性。我们内部给自己定的目标是“每个团队至少贡献两个技能”，这样平台才能形成生态。目前看来，销售团队贡献了客户画像速览，研发团队贡献了日志异常分析，市场团队贡献了舆情摘要，虽然质量参差不齐，但整体上已经不是一个空壳工具了。

3. 核心实操环节：从配置到落地的关键细节

3.1 技能模块的抽象：输入、输出与上下文如何设计

技能模块的设计直接关系到 Agent 能不能“听懂”用户的需求并正确调用。我们最初犯过一个错：把技能的输入参数定义得太细，有七八个必填字段，结果 Agent 经常因为缺少一个字段就放弃调用，用户体验极其糟糕。

后来我们改成“最少必要参数”原则，能用一个参数解决的绝不用两个。比如“查工单”技能，必填只有一个“工单编号”，至于时间范围、状态过滤这些都属于可选参数，缺省时用默认值。实测下来，技能调用成功率从最初的不到六成提升到了八成以上。

上下文设计是另一个重点。技能需要声明自己对上下文的需求类型：有的技能只需要当前会话的消息历史，有的技能需要查询用户身份信息，还有的技能需要访问某个共享知识库的全局索引。我们把上下文权限和技能权限放在一起管理，这样既保证模型有足够信息做判断，又不至于让 Agent 随便读取所有数据。

3.2 系统提示词的工程化：区分“平台级”和“技能级”

系统提示词是所有 Agent 应用里最容易被低估的部分。在 Every Agent 里，系统提示词分两层：平台级提示词由平台团队维护，定义 Agent 的总体行为准则，比如“优先使用技能回答，不确定时向用户确认”“回答涉及内部数据时附带数据更新时间”；技能级提示词由技能开发者维护，只描述该技能的具体执行逻辑和使用边界。

分层的原因很简单：如果把所有规则塞进一整段提示词，维护成本会高到失控。平台级提示词保证所有技能都在同一套行为框架下运行，技能级提示词保证每个技能有足够的灵活性。两者冲突时，平台级优先，这是为了避免业务团队写出一些不符合合规要求的技能行为。

提示词的版本管理同样重要。我们每次改技能级提示词，都会走一次完整的回归测试：准备十到二十个典型提问，对比改版前后的输出质量。这个流程听起来繁琐，但确实能拦住不少“看着聪明、实际翻车”的改动。

3.3 API 连接器的标准化：认证、限流与错误处理

Agent 要真正有用，离不开与内部系统的连接。我们在共享层统一封装了一批 API 连接器，覆盖了工单系统、客户管理系统、数据仓库和文档平台。连接器标准化的核心是认证和限流。

认证这块，我们没有用简单的“全局服务账号”，而是让连接器自动携带“当前用户”的身份凭据。也就是说，Agent 调用工单系统时，后台是以发起对话的那个员工的名义去请求的，这样下游系统的权限控制依然生效。这个设计对合规特别重要，否则就会出现员工 A 通过 Agent 间接查到员工 B 的私密数据。

限流也是必须提前考虑的事。Agent 的调用频率和人类操作完全不在一个量级，某个技能一旦出现逻辑错误，可能在短时间内对下游系统发起数百次请求。我们在连接器层做好了熔断，单用户单技能每分钟最多调用一定次数，超过后直接拒绝并返回友好提示，并记录审计事件。

3.4 知识库接入：共享只读的默认策略与例外机制

知识库是 Agent 回答质量问题的重要保障。Every Agent 接入了公司内部的文档库，覆盖产品手册、技术规范、运营流程等几大板块。默认策略是共享只读，即所有员工都能让 Agent 检索这些文档，但 Agent 不能向知识库里写入任何内容。

这个默认策略省了很多事，但也带来一个问题：不同团队的文档存在语义冲突。比如市场部写“目标用户是企业客户”，销售部写“目标用户是中小企业”，Agent 检索到两篇文档时，回答就会自相矛盾。我们后来在知识库索引里加了“文档来源”字段，并在 Agent 回答时标注信息来源团队，让用户自己判断可信度。

例外机制用于那些需要临时写入的场景，比如“把这次会议纪要把存入项目知识库”。我们允许少数经过授权的技能调用知识库写入接口，但必须记录写入者身份和写入内容。整体上写入请求占比很低，但这道口子保留着，能让流程跑得更顺，不至于所有操作都卡在只读边界上。

4. 落地过程中踩过的坑与排查实录

4.1 权限粒度太粗导致交叉提问漏数据

第一次上线权限方案时，我们做的是“角色级权限”，只区分管理员、普通员工、访客三种角色。上线第二天就出事了：一位销售经理让 Agent 生成本月团队业绩报表，结果报表里包含了另一个团队的数据。事后排查发现，他所在角色拥有“跨团队查询业绩”的权限，但业务上他根本不应该看到这些数据。

这个问题的本质是权限设计只考虑了“技术角色”，没考虑“数据范围”。我们后来改成“技能级权限 + 数据范围约束”，每个技能可以声明允许访问的团队、部门或项目范围。Agent 在实际调用时，会通过连接器自动带上数据过滤条件，从根上避免越权查询。

这个坑给我的教训是：Agent 的权限模型一定要比传统应用更谨慎。因为用户是通过自然语言提需求，他不会主动说“请只查我自己部门的数据”，Agent 需要基于身份和数据权限自行判断。粗粒度的角色控制在这种场景下远远不够。

4.2 上下文窗口被日志任务吃满，正常对话反而变蠢

我们在某个技能里加了“实时日志查询”功能，用户可以问 Agent “看看支付服务最近的错误日志”。起初一切正常，但很快有人发现，只要聊过日志相关的话题，Agent 后续的记忆就变得混乱，经常答非所问。

原因在于日志内容太长了，动辄几千行，直接把上下文窗口塞满，挤掉了前面几轮对话的关键信息。模型在长上下文里的表现会衰减，尤其是中间部分的信息容易被忽略。这个问题在技术上有几种解法，比如摘要压缩、滑动窗口、外部记忆等，但我们最推广的做法是：让日志技能只在“用户明确要求”时才运行，且默认返回摘要而非完整日志。

这个坑其实很典型，它提醒我们，技能设计不能只看功能是否实现，还要考虑它对整个对话上下文的“污染程度”。Agent 不是无限内存的，任何占用大量上下文的操作都要谨慎设计。

4.3 技能冲突：同名“导出报表”两套口径

技能注册表上线一段时间后，有两个团队分别提交了“导出报表”技能，一个是销售口径，一个是运营口径。技能名称一样，系统里直接出现了混淆，用户在提问时，Agent 随机选择其中一个，导致同样的指令拿到完全不同的数据。

解决方案有两个方向：一是强制技能名称全局唯一，二是允许同名但通过描述区分。我们最终选择了后者，但加了一个“默认技能排序”的机制：当多个技能看起来都能回答用户问题时，Agent 优先调用排序靠前、被验证次数更多的技能。同时技能描述里明确标注适用场景和部门归属。

这个坑给我们的启示是：技能注册表不能只做“登记”，还要做“路由决策”的辅助信息维护。技能之间的边界如果模糊，用户体感就是同一条指令时而有效时而无效。定期梳理技能清单、合并重复功能，是平台团队应尽的职责。

4.4 幻觉率在真实业务中不可忽略

联网搜索类技能上线后，我们发现了一个让人头疼的现象：Agent 会用搜索引擎结果里某个网页的片段来回答，却完全不标注信息出处。有用户问“某行业报告的数据是多少”，Agent 直接给了一个看起来很像样的数字，实际上那个数字来自一个过时的博客。

业务场景下的幻觉问题，和技术 Demo 里的体验差距很大。Demo 里错了就错了，顶多重来一次；业务里错了可能导致决策失误、客户沟通翻车。我们的应对措施有三层：一是要求 Agent 在回答涉及外部数据时附上引用来源；二是对数字类回答增加“数据不确定性”提示；三是在关键的业务技能里，强制要求先调用知识库检索再回答，不允许模型凭记忆输出。

即便如此，幻觉也不可能完全归零。我们内部对 Agent 输出的定位是“初稿参考”，不是“最终结论”。这可能不像 AI 宣传片里说的那么智能，但至少不会让公司在关键环节翻车。

4.5 成本治理：共享之后账单反而暴增

Every Agent 上线两个月后，我收到了一份吓人的账单。Token 消耗量比之前分散使用时的总和还高了一截。一查才发现，共享平台带来的便利性大大降低了使用门槛，很多原本不会用 AI 的同事开始高频使用，加上一些技能存在冗余调用，成本自然就上去了。

成本治理因此成了共享平台的重点工作。我们做了几件事：给每个技能设置独立的 Token 预算，用量超过阈值自动告警；对高消耗技能做输出长度限制，比如默认返回摘要而不是全文；推动团队为高频场景配置更便宜的缓存模型。这套组合拳下来，单次请求的平均成本下降了大概三成。

成本问题本质上是个治理问题，而不是技术问题。Agent 平台一旦普及开来，它的消耗就和公司里的打印机纸一样——只要方便，就会有人用得多。反过来想，这也说明共享 Agent 确实被团队接受了，只是我们需要学会给这份便利设置边界。

5. 从这个项目延伸出去：Agent 开发范式的变化

5.1 Agent 正在从“工具”变成“同事”

过去我们用软件的方式是用一个界面操作某些功能，现在用 Agent 的方式是“告诉它目标，让它自己想办法”。这个变化听起来不大，但影响深远。比如 When I ask Every Agent 整理一份某客户的沟通纪要，它不只是把搜索结果拼在一起，而是会主动调取邮件记录、会议转录、工单历史，最后生成一份有时间线、有结论摘要的报告。

这个体验上的提升，来自技能编排和上下文管理的成熟度。当技能注册表里积累了几十个可靠技能后，Agent 就从一个“问答机器人”变成了“能干活的小助手”。这种变化让我意识到，未来的软件交互可能真的会从“点击”转向“对话”，而 Agent 平台就是这种新范式的底座。

对开发者来说，这意味着思维方式要从“写功能”转向“写能力”。你不再关心用户的每一步操作，而是关心你的技能能在什么场景下被 Agent 主动调用。这有点像从开发单体应用转向开发微服务，只不过调用方从代码变成了自然语言。

5.2 平台化的下一步：Agent 编排与团队自治

目前 Every Agent 还停留在“单 Agent 多技能”的阶段，下一个阶段我们打算尝试流程自动化和 Agent 编排。比如“客户成功巡检”流程，可能需要销售数据技能、工单分析技能、文档检索技能按顺序配合执行。单靠一个 Agent 在对话中随机调用技能效率不高，我们需要的是跨技能、多步骤的流程编排。

流程编排的实现思路是把“业务流程”本身定义成一种技能。这种技能会声明前置条件和执行步骤，Agent 在匹配到用户意图后，不是只调一个接口，而是按预设步骤依次调用多个技能。比如“客户成功巡检”就是先查客户基本信息，再查最近工单，接着生成健康度评分，最后输出建议报告。

团队自治也是平台化后要解决的问题。随着技能越来越多，平台团队不可能为每个技能都做详细审核。我们的方向是“平台定标准、团队管内容”，平台团队负责技能开发的框架和审核上线，各业务团队负责自己技能的生命周期管理。放权的前提是标准足够清晰、审计足够完整，不然自治就会变成失序。

6. 实操心得与后续扩展建议

从 Every Agent 这个项目里，我最大的体会是：共享平台的挑战不在技术，而在组织协作方式的调整。技术上的技能注册表、权限模型、上下文管理都是有现成方案可以抄的，真正难的是让不同团队愿意把技能贡献出来、按统一标准开发、接受平台团队的约束。

如果你也想在公司内部做类似的共享 Agent 平台，我的建议是先定好两个边界：一是权限边界，技能能访问哪些数据必须一开始就设计清楚，后面补会非常痛苦；二是职责边界，哪些是平台团队管的、哪些是业务团队管的，要通过清晰的接口区分开，否则很容易变成互相扯皮。

另一个实用的建议是：从第一个技能开始就要建立评估标准。不要只看“回答像不像人话”，要看它能不能稳定调用正确的技能、能不能给出可验证的答案。我们内部建了一个回归测试集，里面是几百条典型问题和对应期望行为，每次技能更新都会跑一遍，这是保证平台质量的最基础手段。

最后想分享一个小技巧：把系统的审计日志打开到最细，然后隔一周翻一次。你会在日志里看到很多用户使用 Agent 的真实方式，这些方式和产品经理想象中的完全不一样。正是这些日志，帮我们发现了很多技能描述不清、路由错误、权限过宽的问题。数据永远比直觉靠谱，这件事在 Agent 平台上体现得尤其明显。