Vibecoding进阶教程-从能用到可控（三）：安全、评测与流水线

2026-04-11 13:361阅读0评论SEO资源
  • 内容介绍
  • 文章标签
  • 相关推荐
问题描述：

Vibecoding进阶教程-从能用到可控（三）：安全、评测与流水线

本篇是 Vibecoding 系列教程第二部分进阶篇的第三篇，也是第二部分的最后一篇。
感谢佬友们一直以来的支持，后面我也会继续产出一些 vibecoding 相关的教程和工具推荐。

  • 前篇（环境搭建 + 基础闭环）：Vibecoding基础教程
  • 如果对您有帮助的话可以帮我点一个star，这个repo我会持续更新的
  • 上一篇：多智能体 + 长任务治理
github.com

GitHub - 1EchA/how-to-vibecoding: Vibecoding 系列教程：从环境搭建到多智能体协作，涵盖 MCP、Skills、Agent...

Vibecoding 系列教程：从环境搭建到多智能体协作，涵盖 MCP、Skills、Agent 分工治理

写在前面

到这里，我们已经跑通了 MCP 工具链和 Skills 卡片，也了解了多智能体分权和长任务治理机制。本篇是系列的收尾，解决最后三个问题：

  • 任务 1：安全加固

  • 任务 2：评测与可观测

  • 任务 3：团队协作与流水线

末尾附录包含一些模板参考和延伸资料。

任务 1：安全加固——第三方 MCP 不只是普通插件，更代表着权限

目标：建立一套接入前的安全审查习惯。不管是用别人的 MCP server 还是自己开发，都要先排查一下隐患。

你把第三方 MCP 接到你的开发环境里，本质上就是给了一个外部程序跟你一样的系统权限。它能碰到的网络、文件系统，基本等于你能碰到的，这是很夸张的。

1.1 接入前需要考虑的 7 个问题

  1. 读写边界：它到底需要读什么，需不需要写权限。

  2. 权限范围：默认权限是不是给太大了，能不能把权限缩到最小目录。

  3. 网络行为：它在工作时会访问哪些网络，请求会发到哪些域名。

  4. 敏感距离：它离你的环境变量、数据库凭据留有多少距离。

  5. 审计日志：它跑的时候，有没有留下可追溯的日志。

  6. 重试风险：超时或报错后的重试，会不会产生副作用。

  7. 供应链：作者靠谱吗，是长期维护的项目还是可能有后门随时有跑路风险的项目。

1.2 给已接入的 MCP 做一次安全审查

可以拿出我们之前做好的 MCP 出来，也可以拿一个比较常用的 MCP 来进行一次审查。

MCP 审查表 Server 名称： 1. 读写边界：只读/读写 2. 权限范围：已限制到子目录/全盘访问 3. 网络行为：网络请求流向 4. 敏感距离：无法访问 .env/数据库/可访问 5. 审计日志：有日志/无 6. 重试风险：操作幂等/有副作用风险 7. 供应链：官方/知名维护者/个人项目

1.3 需要确认的底线

  • 最小权限：只给特定子目录的访问，只开必要的端口。

  • 写入限制：如果必须能写文件，至少限制在 src 或 tmp 下，避免碰到配置文件。

  • 可追溯：最起码你得能看到它调了什么、改了哪几行。

  • 重试克制：别让重试变成死循环。

1.4 用 HTTP MCP 时的安全注意事项

大部分人用的是本地 STDIO 模式（就是在 config 里配 command + args 那种），这种模式 MCP 跑在你自己机器上，安全风险相对可控。

但如果你用的是 HTTP 模式（MCP Server 在远程通过网络调用），那安全要求就会变高，这里说几个推荐大家注意的点：

  • 认证：必须用 OAuth 做身份验证，裸跑的 HTTP MCP 等于把开发环境暴露在公网上。

  • Token：API Token 只能放在请求的 Header 里（Authorization: Bearer xxx），不要拼在 URL 后面，URL 会被日志和浏览器历史记录泄露。

  • 回调：OAuth 回调只允许 localhost 或 https:// 开头的地址，防止 Token 被中间人截获。

延伸阅读：

如果你要把 HTTP MCP 或第三方组件接入长期开发流程，建议看看这几份安全指南。

  • OWASP: Secure MCP Server Development — https://genai.owasp.org/resource/a-practical-guide-for-secure-mcp-server-development/

  • OWASP: Securely Using Third-Party MCP Servers — https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/

  • OWASP Top 10 for Agentic Applications (2026) — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

任务 2：评测与可观测——不再凭直觉对项目进行迭代

这部分主要为了回答一个问题：“改了工作流换了模型之后，效果到底是真的变好了，还是运气呢？”

没有认真的评测量化，日常开发最容易陷入这种情况：

  • 今天一切顺利：“天才程序员诞生了”

  • 明天觉得模型降智：“天才程序员陨落”

其实多半是上下文膨胀了、工具链卡了、或者纯粹运气不好。我们需要一些量化后的证据来看看到底是为什么。

2.1 自己做一套回归测试集

跑和自己业务项目关系不大的 Benchmark 意义不大，有时间的话自己搭一套质检题库是个不错的选择：

  • 3 个有代表性的 Bugfix

  • 3 次 Feature 增量

  • 2 次重构

  • 2 次补核心链路测试

每道题需要写清楚的是：

  • 输入：原始任务描述。

  • 预期：通过条件。

  • 验证：验证命令。

存成 JSONL，方便即拿即用（附录 A 有最小 Schema）

2.2 先用最朴实无华的方式做 Tracing

用 JSONL 把每次操作录下来：

  • trace_id（任务标识）

  • 操作时间

  • 调用的 Tool 名

  • 输入摘要（注意脱敏，去掉 API Key、密码等）

  • 输出摘要

  • 耗时

  • 报错信息

有了这种记录表，才方便在问题出现的时候，快速定位问题到底在哪。

建议：
每条日志一定要带 trace_id。一旦多个 Agent 并行跑或者长任务反复重试，没有 trace_id 的日志直接就乱套了，根本分不清上下游。

2.3 往标准化靠拢

如果打算把这套推给团队用，建议字段命名向 OpenTelemetry (OTel) 的 GenAI semconv 标准看齐。哪怕现在没接 OTel 的全套体系也可以先统一命名，以后迁移成本就会降低很多。

参考：OpenTelemetry GenAI Semantic Conventions — Semantic conventions for generative AI systems | OpenTelemetry

2.4 进阶：从日志到可视化看板

纯看 JSONL 几十次调用确实难受。可以考虑加一层可视化：

  1. 底层还是存 JSONL（这是保底的原始日志）。

  2. 上面接一个可视化平台（Langfuse / Phoenix / LangSmith……）。

  3. 需要注意的有 4 个关键指标：

  • 各类任务的通过率

  • 单次 Bug 修复的端到端耗时

  • 每个环节的 Token 消耗

  • 失败时卡在哪一环

之后就可以比较方便地拉出某次失败任务的完整链路了。

改完prompt后也可以用数据来对比前后的通过率和耗时差异。

延伸阅读：

想深入了解评测和追踪的实践：

  • Inspect AI (UK AISI) docs — https://inspect.aisi.org.uk/

任务 3：团队协作与流水线

第一次让两个 Agent 同时去修同一个文件的人，通常会收获一份完美的合并冲突。

本节适用于有 CI/CD 环境、多人协作的团队项目。如果你目前是单人本地开发，可以直接跳过。

3.1 沙盒（Sandbox）

有一个现实是必须接受的：幻觉导致的抽风瞎写发散是不可能完全消除的。所以我们能做的就是考虑怎么降低在幻觉出现时可能造成的负面影响。

做法：

  • 所有试运行、构建、测试都扔到无状态容器或临时沙盒里跑。

  • 只有测试全部通过之后，才允许把 diff 补丁合回主干。

  • 高危操作（删包、重建根目录、大规模推改）要求 coding agent 申请人工审批。

3.2 固定流水线中的关卡

这里面举三个例子：

  1. 静态检查：lint + 类型检查，语法级别的低级错误直接拦掉。

  2. 业务逻辑：跑一遍本次改动涉及的单测或集成测试，确认功能没被改坏。

  3. 安全扫描：有没有硬编码密钥、有没有引入高危依赖，发现了就打断。

如果有关卡没过就退回重来。

对修复主导权本篇也给出两套参考方案：

  • 让 CI job 本身带修复能力，跑挂了直接读 stderr 开始纠错循环，修好了打一个 patch commit。

  • CI 只负责跑测试和报告结果，出了问题通过 Webhook 把错误现场发给远端的 Agent 服务，Agent 打好补丁后 Push 分支等人来审。

3.3 多 Agent 并发时的保护机制

如果你有多个 Agent 同时干活需要注意这两个问题：

  • 同一时刻只允许一个 Builder 有写权限，其他角色（Scout / Verifier）在同一时刻只读。

  • 写入前必须同步最新的上游状态，避免两个 Agent 各写各的然后互相覆盖。

常见的实现方式：

  • 文件锁：在写入和跑测试的入口用 flock 之类的工具加锁，另一个 Agent 过来发现被占了就直接排队或报错。

  • Git 保护：每次写入前强制 git pull --rebase，有冲突就中断当前轮次。

如果你用的是 Codex 的 worktree 模式，它已经帮你做了隔离，每个 Agent 在独立的 worktree 里工作，基本不会冲突。这节主要是给自己搭框架的团队看的。

延伸阅读：

  • Codex Security（沙箱 / 审批 / 网络策略）— Codex Security

  • Dagger Docs（容器化可复现流水线）— https://docs.dagger.io/

  • The Harness Problem — I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. | Can.ac

附录 A：模版案例参考

A.1 项目规则模板（放在根目录的 AGENTS.md）

## How to run - Install： - Test： - Build： ## Collaboration rules（协同规矩） - 动手前先给我 3-7 步计划，标注每一步怎么验证。 - 改完必须贴 diff，不要只给总结。 - 收工前自觉跑 lint、test、build。跑不了的说明原因。 - 任何情况都不许泄露 secrets（.env、key、token、credentials）。 - 最小化改动，不要为了美观重构大片代码。 ## Stop conditions（什么时候必须停手） - 要引入新依赖或做大版本升级。 - 改动超过 5 个文件。 - 连续 2 次排错失败找不到原因。

A.2 需求描述模板

## Context（背景） （说明：仓库定位 / 相关模块 / 限制条件） ## Goal（目标） （一句话说清你想要什么效果） ## Acceptance criteria（验收标准） - （使用什么命令可以校验结果） ## Constraints（约束） - 不泄露 secrets - 最小化改动 ## Delivery（必须交付） 1) 计划 2) 代码改动 3) 关键 diff 4) 验证通过的输出

A.3 MCP Server 开发 checklist（STDIO 模式）

  • 绝不往 stdout 写日志（调试信息走 stderr）。

  • 先在本地跑通，再对接远端或外部 API。

  • 每个 tool 都要定义清楚：入参类型（schema）、返回结构、错误处理、超时限制。

  • 明确读写范围：它能触及的目录有哪些，是否有被限制在子目录中。

  • 写操作尽量做到多次调用不产生副作用。

A.4 HTTP MCP 的授权 checklist

  • 通讯走 HTTPS

  • redirect URI 严格校验

  • Token 走 Authorization header（不放 query string）

  • 配置 PKCE

  • 按标准走 metadata discovery（.well-known/oauth-authorization-server）

A.5 多智能体角色模板

见前一篇

Vibecoding进阶教程-从能用到可控（二）：拒绝coding agent既当裁判又当运动员

A.6 评测回归库的 JSONL 模板

记录好输入和验收标准，每次升级后全部重跑。

{"id":"bugfix-001","title":"修复计算模块的单测崩溃","input":"...","acceptance":["npm test 全部通过"],"verify":["npm test"],"tags":["bugfix","tests"]}

A.7 Tracing 的 JSONL 模板

每条带时间戳、耗时和 trace_id，事后排查不用瞎猜。

{"trace_id":"bugfix-123-run-1","ts":"2026-03-03T10:00:00Z","tool":"bash","input_summary":"npm test","output_summary":"passed","duration_ms":12345,"error":null}

附录 B：延伸阅读与官方参考资料

MCP 协议与 Server 开发：

  • MCP Introduction — What is the Model Context Protocol (MCP)? - Model Context Protocol

  • MCP Quickstart: Build a server — Build an MCP server - Model Context Protocol

  • MCP Specification — Versioning - Model Context Protocol

  • modelcontextprotocol/typescript-sdk README — https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.md

  • modelcontextprotocol/python-sdk README — https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.md

MCP 生态与官方参考：

  • modelcontextprotocol/registry README — https://raw.githubusercontent.com/modelcontextprotocol/registry/main/README.md

  • modelcontextprotocol/servers README — https://raw.githubusercontent.com/modelcontextprotocol/servers/main/README.md

  • MCP Apps (interactive UI) — MCP Apps - Bringing UI Capabilities To MCP Clients | Model Context Protocol Blog

  • modelcontextprotocol/ext-apps README — https://raw.githubusercontent.com/modelcontextprotocol/ext-apps/main/README.md

  • Introducing the Model Context Protocol (Anthropic) — https://www.anthropic.com/news/model-context-protocol

  • Donating MCP and establishing the Agentic AI Foundation (Anthropic) — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation

HTTP MCP 的 OAuth 授权（看情况选读）：

  • MCP Authorization (OAuth 2.1) — https://modelcontextprotocol.io/specification/basic/authorization

MCP 生产环境安全指南：

  • OWASP: Secure MCP Server Development — https://genai.owasp.org/resource/a-practical-guide-for-secure-mcp-server-development/

  • OWASP: Securely Using Third-Party MCP Servers — https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/

  • OWASP Top 10 for Agentic Applications (2026) — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

  • Teleport RFD 0209: MCP access — https://raw.githubusercontent.com/gravitational/teleport/master/rfd/0209-mcp-access.md

Skills 与规则标准：

  • anthropics/skills README — https://raw.githubusercontent.com/anthropics/skills/main/README.md

  • agentskills/agentskills README — https://raw.githubusercontent.com/agentskills/agentskills/main/README.md

  • Agent Skills Standard (agentskills.io) — https://agentskills.io/

  • agents.md (AGENTS.md spec) — - Always run `pnpm lint` and `pnpm test` before committing. ``` ## Website This repository also includes a basic Next.js website hosted at https://agents.md/ that explains the project’s goals in a simple way, and featuring some examples. ### Running the app locally 1. Install dependencies: ```bash pnpm install ``` 2. Start the development server: ```bash pnpm run dev ``` 3. Open your browser and go to http://localhost:3000

  • upstash/context7 README — https://raw.githubusercontent.com/upstash/context7/master/README.md

多智能体协作：

  • Claude 的高级工具调用（Anthropic 工程文章）— https://www.anthropic.com/engineering/advanced-tool-use

  • Building effective agents — https://www.anthropic.com/research/building-effective-agents

  • How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system

  • openai/swarm README — https://raw.githubusercontent.com/openai/swarm/main/README.md

  • OpenAI Agents SDK (Python) docs — OpenAI Agents SDK

  • Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

  • Measuring AI agent autonomy in practice — https://www.anthropic.com/research/measuring-agent-autonomy

长任务管理：

  • oh-my-opencode README — https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/dev/README.md

  • oh-my-claudecode README — https://raw.githubusercontent.com/Yeachan-Heo/oh-my-claudecode/main/README.md

  • The Harness Problem — I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. | Can.ac

评测与可观测：

  • Inspect AI (UK AISI) docs — https://inspect.aisi.org.uk/

  • OpenTelemetry GenAI Semantic Conventions — https://raw.githubusercontent.com/open-telemetry/semantic-conventions/main/docs/gen-ai/README.md

  • OpenTelemetry GenAI Agent Spans — https://raw.githubusercontent.com/open-telemetry/semantic-conventions/main/docs/gen-ai/gen-ai-agent-spans.md

  • SWE-bench benchmark repo — https://raw.githubusercontent.com/swe-bench/SWE-bench/main/README.md

  • SWE-bench-Live benchmark repo — https://raw.githubusercontent.com/microsoft/SWE-bench-Live/main/README.md

跨平台协议与前沿实践：

  • A2A Protocol Specification — https://github.com/a2aproject/A2A/raw/main/docs/specification.md

  • openclaw/openclaw README — https://raw.githubusercontent.com/openclaw/openclaw/main/README.md

网友解答：
--【壹】--：

佬们更强

--【贰】--：

满满干货

--【叁】--：

大佬 你太强了，我要把你的教程打印出来

--【肆】--：

建议你的帖子申请精华

--【伍】--：

感谢EA佬的满满干货，已经收藏

--【陆】--：

强无敌教程

--【柒】--：

感谢！干货收藏了

--【捌】--：

学习一下

--【玖】--：

感谢分享

--【拾】--：

学习学习，佬太强了

--【拾壹】--：

先mark后看

--【拾贰】--：

哇！感谢大佬