文章总结： 文章复盘用23亿Token、Cursor+Claude把35万行AI草稿炼成8万行企业级AgenticSOC的工程闭环：以ModelAsAgent、AgentAsEngineer理念让AI虚拟SOC团队接管L1-L3告警、应急、报告；给出架构-编码-测试-文档全流程AI协作规则，强调先Gemini可行性再Opus细化、拒绝降智模型、强制结构化输出、HITL+HonestyAgent反幻觉、TDD+性能验证防AI改测试、文档即记忆库，最终Token成本从5元/行降到0.1元/行并输出可复制的AI安全平台范式 综合评分： 88 文章分类： AI安全,安全建设,安全运营,渗透测试,解决方案

0x03 实战避坑指南：那些烧掉Token换来的教训

1. 模型接口与编程工具 (Model & Tooling)

• 模型分级（Model Selection）：

• ⚡️拒绝“降智/弱智”模型：在ReAct Loop中，Tier 1级别（如Opus 4.5/Gemini 3.5 Pro）能完成完整闭环，而Tier2/ Tier3 模型往往只能Loop几轮或者一轮就结束；对于核心逻辑，坚决不使用低智力模型。

• ⚡️安全场景的适配性：避免使用“道德水准” 较高导致无法进行红队模拟的模型。在渗透场景中，这类任务会被模型拒绝的；

• 对抗幻觉（Anti-Hallucination）：

• ⚡️HITL (Human-in-the-Loop) ：关键步骤必须引入 ask_human 强制人工介入。但需要注意：由于AI输出的不稳定性，返回的指令可能是ASK_HUMAN 或 ask_human，代码中需要统一lower()处理，否则会导致前端弹窗失败；

• ⚡️Honesty Agent：引入独立的“诚实监督代理”，采用Direct（一轮）模式开启独立会话，专门用于校验工具输出与模型响应逻辑的一致性，防止瞎造数据；

• ⚡️Fact Verify: 简单的正则表达式，在HITL和Honesty Agent之前用来检测数据的实体对应的格式；

• 工具差异：

• ⚡️SDK鉴权差异：使用官方模型与第三方代理时，SDK传参往往不同。例如Claude原厂使用ANTHROPIC_API_KEY，而某些代理商给的SK则需要通过ANTHROPIC_AUTH_TOKEN传参；

• ⚡️Claude CLI 的“默认回退”：在Claude CLI中即便选择了Opus模型，在连接到Cursor IDE后通过ClaudeCode界面时仍可能静默回退到Default模型（使用Sonnet或Haiku）。需要多次强制确认配置，否则可能会导致代码质量突然下降。

• ⚡️Embedding兼容性：不同模型（OpenAI/Gemini/Qwen）提供的Embedding Chunk Size不同，切换AI Model Provider时须做兼容性测试。

• ⚡️模型工具的知识时效性：模型的数据知识有限，无论是Anthrropic家，Google家，在产生AI Model Provider得代码时往往预设的是Gemini 1.5 pro，GPT3o之类，不知道使用最新的模型参数。同时，Claude CLI在实现集成Anthrpoic的代码时，最为费力。不是忘了Header头，就是忘了参数。（这个也可能是和代理模型有关）

2. 数据流与交互 (Data Flow & Interaction)

• 结构化输出（Structured Output）：

• ⚡️严禁直接执行字符串：绝不建议直接使用LLM输出的字符串作为命令执行。LLM 拼接的JSON极易出现多次转义问题。必须强制要求 Structure Output（e.g. Pydantic对象），并进行严格过滤。让LLM做填空题;

• ⚡️格式归一化：不同模型对同一Prompt的输出格式千差万别。前端渲染前，必须在中间层实现格式清洗（Formatter），确保UI行为一致。或者插入特定的symbol，emoji都可以，用来截断和格式清洗；

• 数据打通（Data Fabric）：

• ⚡️组件间流通：平台内部组件（MCP Server, RAG Storage, Chat）之间的数据孤岛问题，建议通过OSS（对象存储）构建Data Fabric来打通。 例如⚡️Remote Terminal MCP Server需要通过OSS存储才能拉取到chat中上传的文件（这个是因为之前Platform和红队Infra部署在不同的Server上）

• 技术选型的 ROI

• ⚡️要简洁优雅架构：在组件选型时，优先选择简单易扩展的产品（如 Qdrant），而不是部署复杂的庞然大物（如 Milvus）。后者可能让你花费100美元实现特性和调试集成Bug，然后第二天又得花费50美元回退代码。而对Qdrant的file based存储，就能实现在2k-2w个数量的文档中实现50ms内的查询。

3. 环境与性能 (Environment & Performance)

• 开发环境一致性 (DevOps)：

• ⚡️Docker 路径挂载：本地Dev与远程Docker环境经常出现路径不一致。务必检查Volume挂载路径，或通过Data Fabric解耦文件依赖。（不过我现在已经更换成Native Deployment了，仅把DB用docker起服务）；

• 构建陷阱：警惕npm run dev正常但npm run build报错的情况。远程部署时，务必使用docker compose build --no-cache避免旧缓存导致的神秘Bug…..

• ⚡️运行时版本：Ubuntu默认Node.js为18.x，若前端依赖22.x，Native 部署时必须先安装 NVM。且AI编写的Start脚本往往忽略pip install或npm install的网络失败，需要教 AI 增加错误检查逻辑。在运维类脚本的实现过程中，Vibe Coding的出错率大的惊人，或者说兼容性一般。无论是init let’s encrypt的shell脚本，还是起system services,还是web服务文件目录的权限，以及服务用户的权限配置等。相较而言，docker部署能够杜绝掉这些问题。

• 性能优化的悖论：

• ⚡️Gzip vs SSE：优化后端性能时，开启Gzip压缩会由网关缓冲数据，导致SSE流式输出失效，前端对话出现严重的“卡顿感”。流式业务不建议开启 Gzip。 （也可能是我配置错误了）

• ⚡️缓存覆盖风险：引入React Query缓存后，需警惕过期数据覆盖新数据。例如点击重命名Chat后，前端30秒的自动缓存可能瞬间将新名字覆盖回旧名字。

• ⚡️跑分里的高分低能：跑性能测试，显示前端代码Best Practice评分达到100分，Performance只有25分。代码规范不等于运行时性能，必须以真实加载时间为准。

0x03 总结

回顾Cursor的2025年度报告，我消耗了约700M Token。除去其中100M用于几个“玩具”Demo的，剩下的绝大部分Token都熔铸进了Agentic SOC平台的构建中（主要消耗在Gemini-3-Pro上）。项目初期，我粗略测算过构建框架的成本，3-5元/行代码；而后期在功能填充实现时的成本大约是0.5元/行，至于文档编写，成本更是低至0.1元/行。

在Token计费的时代，每一次对话本质上都是在支付💲。架构设计的优劣，也直接决定了你是把钱花在刀刃上，还是烧在无效的上下文里。

其次作为Cursor Ultra用户，我不得不吐槽其近期的更新策略。频繁的Update & Install带来的没看到功能的飞跃，而是使用习惯的的破坏——Agent和文件夹的看板在左右侧反复横跳，侧边栏折叠逻辑也是改来改去。这也引出了另一个关于工具选型的教训：不要盲目囤积AI Coding的会员。 我曾图便宜订阅了Trae的年费会员，同样的Prompt，声称使用“同样的模型”，却生成了完全不在一个Level的代码。这也从侧面说明，在AI基础设施层，“便宜”往往意味着模型能力的静默降级。对于使用者而言，识别工具的真实能力比收集Logo更重要。而浪费在便宜的工具上最后则消耗了更珍贵的时间和精力。

AI时代，10倍工程师进化为100倍工程师不再是神话。但这也有一个前提：必须具备对输出结果的鉴别判断能力”。如果没有软件工程的约束，投入再多的Token也产不出企业级产品。我从不焦虑被AI淘汰，因为我知道LLM迭代得越快，对领域知识和架构决策力的要求反而越高。投入才有产出，持续深耕专业领域，学习、实践并输出，才能更经得起检验。

参考

• 参考链接微信排版不显示：可点击访问原文查看或
• https://fz.cool/ai-software-engineing-with-project-agentic-soc-design-and-implement/
• MCP 安全“体检” | AI 驱动的 MCP 安全扫描系统
• AI for 安全攻防：自动化渗透 Agent 的工程设计与实践（Agent Pattern Graph 与 Meta-Tooling）
• This Buzzy Cyber Startup Wants to Take On Dangerous AI Threat
• AI编程实践总结
• 软件工程实践：以Python为例
• 从删库到跑路：我的Python全栈踩坑实录
• codeguide
• Claude Agent Skills
• Use Claude Code in VS Code
• AI coding 智能体设计

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：放之 放之 放之《AI软件工程实践：构建企业级Agentic SOC平台》