Agent 平台从原型到生产的实战经验

我构建了一个 Agent 平台。不是 demo，而是一个真正的平台：每一次工具调用都受到治理、经过审计，并且被限定在特定 workspace 内。

以下是我从中学到的经验。

每项 Skill 都是一等公民

这个平台包含 7 个类别、共 27 项 Skill，覆盖平台运维、内容发布（dev.to、LinkedIn）、测试（完整的 TEA 套件，包括风险矩阵、基线特征分析和 NFR 审计）、通信（Slack、Telegram、Gmail）、知识（RAG + 持久化记忆）、开发以及数据抓取。

Skill 不只是 prompt。每一项 Skill 都有一套受治理的生命周期：创建、验证、版本管理，以及添加到 workspace 中。不存在散落在各处、脱离管理的脚本。

14 项集成服务，一条审计链路

GitHub（issue/PR）、Jira（工单）、Slack 和 Telegram（消息通信）

Gmail、Google Calendar、Google Drive（OAuth2）

LinkedIn（个人资料 + 帖子发布）、Dev.to（博客）

Knowledge Base（RAG 检索）、Memory（跨会话持久化）

Web Search、Transcribe（Whisper）

每一次对外调用都会经过 platform_cli 的 dispatch 操作或 service_call 适配器——使用同一条审计管道、同一个 trace ID。

CLI 是唯一可信来源

你不能只是编辑配置文件，然后期待它能正常工作。你需要使用 loop_list、policy_show、skill_list、service_list 和 workflow_catalog 进行验证。如果在那里看不到，它就不存在。

测试不是事后补救

TEA（Test Engineering Architecture，测试工程架构）套件提供了 6 个 workflow：测试设计（风险矩阵）、基线特征分析（golden-master 差异比对）、NFR 证据审计、自动化测试生成、测试审查，以及从需求到测试覆盖率的追踪。所有输出都会以 JSON 或 markdown 格式提交，不使用任何专有格式。

并非所有功能都已达到生产可用状态。在 27 项 Skill 中，有 4 项处于阻塞状态（缺少对应服务或超出了 workspace 的范围）。模型使用 deepseek-chat，并以 deepseek-reasoner 作为 fallback——务实，不追求新奇。workspace 中的临时文件 TTL 为 24 小时。高风险命令（kubectl delete、helm uninstall）会通过模式匹配被阻止。

但核心思路是可行的：让 Agent 工具受到治理、被限定在 workspace 范围内，同时具备真正的服务集成、真正的记忆能力和真正的审计机制。这已经超过了大多数 Agent 框架所能提供的能力。

如果你正在构建需要调用真实 API，而不只是生成文本的 Agent，不妨考虑以下原则：每一项集成都应成为一项受治理的 Skill，每一次调用都应被追踪，并且你应当能够通过从平台回读数据来验证状态，而不是依靠猜测。

对于后续操作，你可以考虑屏蔽此人和/或举报滥用行为。