个人作品集 · 企业级 AI Agent 平台 0 → 1

企业安全 AI 员工平台

让企业像管理真实员工一样,管理 AI 的技能、权限、审批与审计

它做的其实是一件反直觉的事:把能自主行动、会调用工具的 AI,从"自由执行"收进一套可授权、可决策、可拦截、可追溯的企业执行体系。这里介绍这个产品是什么,以及我在其中做了哪些工作。

0→1
主导产品从定义到 MVP
13
沉淀的 PRD 核心模块
8
拆解出的平台能力域
5
漏洞运营数字员工角色
~3个月
定义 → PRD → 原型 → MVP

产品是什么

一套让安全 SOP 被 AI 受控执行的操作系统

安全运营不是一次性问答,而是持续执行的业务过程——漏洞处置、告警研判、巡检合规、报告撰写,都有明确的输入、步骤、判断依据和审批边界。企业缺的不是又一个能聊天的 AI,而是一套能让 AI 在明确身份、职责、权限和审计下,持续把这些活干完的生产体系。

这套企业安全 AI 员工平台把安全团队已有的 SOP、工具能力、凭证权限、审批要求和审计留痕,组织成可执行、可管控、可追踪的数字员工体系。它不替代漏洞管理平台、告警管理与安全分析平台、终端安全系统这些既有系统,而是把它们的能力纳入数字员工的受控执行链路。

它做什么

+把安全岗位定义成有职责边界、技能范围、运行目标的数字员工
+把文本 SOP 编排成图引擎工作流,让每一步可执行、可观测
+通过 Skill / HTTP API / MCP 接入漏洞管理、告警管理、终端安全、工单与企业 IM
+用凭证保险箱、审批、人工决策、拦截把高风险动作管起来
+用任务中心还原每一次执行,沉淀可审计的证据链

它不做什么

不替代漏洞管理、告警管理、终端安全、工单等既有业务系统
不成为资产、漏洞、告警、工单的主数据系统
不要求客户把已有安全运营数据搬过来
不绕过客户既有的权限、凭证、审批和合规要求
不承诺无人化替代——强调 AI 减负 + 人审兜底 + 全程留痕

核心能力

八个能力域,把"让 Agent 干活"变成"可治理地干活"

产品的关键不在于让 Agent 能对话,而在于把 Agent 的能力拆成企业可控的平台模块。下面是核心能力域,以及它们当前的落地口径。

01

数字员工管理

岗位、职责、技能、运行时、状态——把安全岗位转成可管理的执行主体,每个员工与一个 Runtime 端点映射。

核心能力
02

工作流 / 图引擎

Markdown SOP 表达意图,GraphDefinition 表达执行合约,节点级审批与可观测让流程真正落地。

主线演进
03

任务中心

workflow / cron 两类触发,tasks → 执行图 → 执行节点,把"AI 做了什么"从黑箱变成可追踪状态机。

核心能力
04

Skill / MCP 工具

已完成 MCP 服务与工具发现的基础接入;凭证注入、风险分级和运行时下发随场景继续验证。

基础接入
05

凭证保险箱

AES-256-GCM 加密托管各类凭证,密钥不进对话,查看明文需二次认证,全程写审计日志。

核心能力
06

审批 · 人工决策 · 拦截

三种边界:审批处理"允许但需确认",人工决策处理"需要人给业务判断",拦截处理"红线禁止"。

核心能力
07

通知 · IM · 审计

飞书 / 钉钉 / 企微 / SMTP / Webhook 主动触达,IM 内审批与决策卡片,任务与工具调用沉淀为可回放证据链。

核心能力
08

知识库 · 记忆反思

规划接入带引用的外部知识检索、候选记忆归纳和运行反思;这些能力不作为当前 MVP 的已交付结果。

规划能力

总体架构

平台承载业务控制,执行引擎与既有系统按层接入

整体架构按业务场景、数字员工、编排能力、安全治理、执行引擎和业务系统分层,便于在一张图中说明产品边界与依赖关系。

L1
业务场景层
漏洞闭环告警研判巡检合规攻击面巡检权限审计
L2
数字员工层
岗位身份职责边界任务目标执行上下文
L3
编排与能力层
图引擎工作流SkillMCP Tool Hub知识库记忆反思任务中心
L4 · 收缰的一层
治理与安全层
RBAC多租户凭证保险箱风险审批审计诊断通知协作
L5
Runtime 层
会话执行工具调用流式事件运行时代理日志回传
L6
业务系统层
漏洞管理告警管理终端安全工单企业 IM报表企业知识库
治理与安全层是整套设计的题眼。 高风险动作必须可审批、可拦截、可回放;执行过程要能从任务、节点、工具、审批、通知和日志多维追溯。这一层的存在,才让"自主的 AI"敢进生产环境。

一个真实场景

漏洞智能体:一个 Leader 调度一支数字员工小队

最适合优先落地的尖刀场景。客户通常已有漏洞管理平台、资产数据、漏洞情报、审核流程和修复工单,数字员工从四类高频任务切入,由 Leader 按意图分流,而不是让一个 Agent 把所有事揉在一起。

漏洞运营场景包

Leader + 4 子员工

Leader 接收用户意图,识别是监管通报、漏洞审核、资产扫描还是修复建议,调度对应子员工;每一次调度、工具调用、人工决策、审批和结果都进任务中心,形成可追溯证据链。

Leader · 意图分流 ──▸ 按业务边界调度下面四类子员工
应急排查员
reg_vuln_
emergency_triage
审核处置员
vuln_review_
handle
扫描调度员
asset_scan_
dispatch
修复顾问
vuln_fix_
advisor

场景里藏着大量真实的产品边界判断:审核处置员是无人值守设计、正文收敛为固定结论块便于落库;扫描下发只返回任务 ID,结果由查询技能在人工需要时主动触发,不把异步任务误写成同步闭环;修复建议必须给到命令、配置项、补丁号和验证方法,不能只写"升级到安全版本"。

为什么做与我做出的关键决策

从一个可验证的尖刀场景切入,再把生产边界立住

Agent 技术正在从问答走向工具执行,同时甲方安全团队长期存在“工具多、人力少、SOP 明确但执行依赖人”的问题。这个机会判断决定了产品不从大而全的平台叙事起步,而是先验证一条真实、重复且可度量的安全运营链路。

01

不做通用聊天入口,以漏洞运营作为首个尖刀场景

漏洞运营已有明确角色、SOP、工具和审批边界,既能让客户快速判断产品是否贴近现状,也能验证数字员工从识别意图到调用工具、等待人工判断和沉淀结果的完整链路。

机会判断场景选择MVP 范围
02

把推理与企业执行控制分开

Runtime 负责推理并提出工具意图,平台负责工具执行、权限、凭证、审批、拦截和审计。高风险动作必须经过人工确认或被系统拦截,让底层 Agent 可以迭代,同时不改变企业侧的授权与责任边界。

架构取舍风险边界人在回路
03

协作边界

我负责机会判断、产品定义、方案取舍、平台架构对齐、PRD 和 AI 协作研发;研发与测试团队负责正式工程实现、联调、测试和质量验证。

本人职责团队协作
04

当前结果

约 3 个月推进到 MVP,形成 13 个 PRD 模块和 5 类漏洞运营 AI 角色;当前处于客户 POC 与场景验证阶段,不作为规模化商业结果表述。

MVPPOC 验证如实披露

AI 协作研发方法

人负责判断和责任,AI 负责检索、草拟和执行

这个平台本身就是用 AI 协作的方式做出来的。团队把功能开发、Bug 修复、部署和代码定位这些高频动作沉淀成一整套项目专属的 Skill,靠说明书而不是靠记忆和口头传达保证一致性。

01

功能开发

需求先对齐方案边界,开发时覆盖前端到后端单进程服务的全栈实现,完成后把接口和数据模型细节回填进需求文档,代码和文档不脱节。

02

Bug 修复

复现、定位、修复走统一路径,覆盖前后端、容器和 Runtime 层排查场景;复杂问题先系统化定位根因,不凭经验直接猜。

03

代码定位

定位代码不靠逐文件翻找:用代码知识图谱直接查"谁调用了这个函数""改这里会影响什么",结构化答案比一层层搜快一个量级,跨模块调用链尤其明显。

04

部署

统一部署入口,按意图路由到本地开发部署、生产服务器部署或镜像仓库推送三条路径,减少"到底该跑哪个脚本"的判断成本。

05

提交协作

提交前自动识别当前开发者身份并与主干同步,避免误操作主分支;代码审查走结构化模板,按需求一致性、代码质量、架构和生产就绪度分级给意见。

06

经验沉淀

任务完成后自动提炼可复用模式、记录踩过的坑,把个人经验沉淀成团队资产,而不是做完就忘、下次重新踩坑。

AI 适合做
  • 快速读代码、构建调用链
  • 生成候选修复路径
  • 执行机械性改动和测试
  • 从 commit / task / docs 抽取经验
人必须把关
  • 判断是产品架构问题,还是单纯的代码 bug
  • 判断改动是否触及权限、租户隔离、审计责任
  • 判断要不要把局部修复升级为平台契约
  • 判断哪些内容值得进入长期记忆