Vibecoding进阶教程-从能用到可控(三):安全、评测与流水线

Vibecoding进阶教程-从能用到可控(三):安全、评测与流水线本篇是 Vibecoding 系列教程 第二部分进阶篇的第三篇 也是第二部分的最后一篇 感谢大佬们一直以来的支持 后面我也会继续产出一些 vibecoding 相关的教程和工具推荐 前篇 环境搭建 基础闭环 Vibecoding 基础教程 如果对您有帮助的话可以帮我点一个 star 这个 repo 我会持续更新的 上一篇 多智能体 长任务治理 github com

大家好,我是讯享网,很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



github.com

图片

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

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

  • 任务 1:安全加固
  • 任务 2:评测与可观测
  • 任务 3:管理超大仓库与流水线
    末尾附录包含一些模板参考和延伸资料。



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

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

  1. 读写边界:它到底需要读什么,需不需要写权限。
  2. 权限范围:默认权限是不是给太大了,能不能把权限缩到最小目录。
  3. 网络行为:它在工作时会访问哪些网络,请求会发到哪些域名。
  4. 敏感距离:它离你的环境变量、数据库凭据留有多少距离。
  5. 审计日志:它跑的时候,有没有留下可追溯的日志。
  6. 重试风险:超时或报错后的重试,会不会产生副作用。
  7. 供应链:作者靠谱吗,是长期维护的项目还是可能有后门随时有跑路风险的项目。

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

MCP 审查表 Server 名称: 1. 读写边界:只读/读写 2. 权限范围:已限制到子目录/全盘访问 3. 网络行为:网络请求流向 4. 敏感距离:无法访问 .env/数据库/可访问 5. 审计日志:有日志/无 6. 重试风险:操作幂等/有副作用风险 7. 供应链:官方/知名维护者/个人项目 
  • 最小权限:只给特定子目录的访问,只开必要的端口。
  • 写入限制:如果必须能写文件,至少限制在 srctmp 下,避免碰到配置文件。
  • 可追溯:最起码你得能看到它调了什么、改了哪几行。
  • 重试克制:别让重试变成死循环。

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

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

  • 认证:必须用 OAuth 做身份验证,裸跑的 HTTP MCP 等于把开发环境暴露在公网上。
  • Token:API Token 只能放在请求的 Header 里(Authorization: Bearer xxx),不要拼在 URL 后面,URL 会被日志和浏览器历史记录泄露。
  • 回调:OAuth 回调只允许 localhosthttps:// 开头的地址,防止 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/

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

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

  • 今天一切顺利:“天才程序员诞生了”
  • 明天觉得模型降智:“天才程序员陨落”
    其实多半是上下文膨胀了、工具链卡了、或者纯粹运气不好。我们需要一些量化后的证据来看看到底是为什么。



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

  • 3 个有代表性的 Bugfix
  • 3 次 Feature 增量
  • 2 次重构
  • 2 次补核心链路测试
    每道题需要写清楚的是:




  • 输入:原始任务描述。
  • 预期:通过条件。
  • 验证:验证命令。
    存成 JSONL,方便即拿即用(附录 A 有最小 Schema)




用 JSONL 把每次操作录下来:

  • trace_id(任务标识)
  • 操作时间
  • 调用的 Tool 名
  • 输入摘要(注意脱敏,去掉 API Key、密码等)
  • 输出摘要
  • 耗时
  • 报错信息
    有了这种记录表,才方便在问题出现的时候,快速定位问题到底在哪。



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

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

  1. 底层还是存 JSONL(这是保底的原始日志)。
  2. 上面接一个可视化平台(Langfuse / Phoenix / LangSmith……)。
  3. 需要注意的有 4 个关键指标:
  • 各类任务的通过率
  • 单次 Bug 修复的端到端耗时
  • 每个环节的 Token 消耗
  • 失败时卡在哪一环
    之后就可以比较方便地拉出某次失败任务的完整链路了。



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

延伸阅读:

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

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

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

做法:

  • 所有试运行、构建、测试都扔到无状态容器或临时沙盒里跑。
  • 只有测试全部通过之后,才允许把 diff 补丁合回主干。
  • 高危操作(删包、重建根目录、大规模推改)要求 coding agent 申请人工审批。

这里面举三个例子:

  1. 静态检查:lint + 类型检查,语法级别的低级错误直接拦掉。
  2. 业务逻辑:跑一遍本次改动涉及的单测或集成测试,确认功能没被改坏。
  3. 安全扫描:有没有硬编码密钥、有没有引入高危依赖,发现了就打断。
    如果有关卡没过就退回重来。



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

  • 让 CI job 本身带修复能力,跑挂了直接读 stderr 开始纠错循环,修好了打一个 patch commit。
  • CI 只负责跑测试和报告结果,出了问题通过 Webhook 把错误现场发给远端的 Agent 服务,Agent 打好补丁后 Push 分支等人来审。

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

  • 同一时刻只允许一个 Builder 有写权限,其他角色(Scout / Verifier)在同一时刻只读。
  • 写入前必须同步最新的上游状态,避免两个 Agent 各写各的然后互相覆盖。
    常见的实现方式:




  • 文件锁:在写入和跑测试的入口用 flock 之类的工具加锁,另一个 Agent 过来发现被占了就直接排队或报错。
  • Git 保护:每次写入前强制 git pull --rebase,有冲突就中断当前轮次。
  • 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
GPT plus 代充 只需 145 How to run - Install: - Test: - Build: Collaboration rules(协同规矩) - 动手前先给我 3-7 步计划,标注每一步怎么验证。 - 改完必须贴 diff,不要只给总结。 - 收工前自觉跑 lint、test、build。跑不了的说明原因。 - 任何情况都不许泄露 secrets(.env、key、token、credentials)。 - 最小化改动,不要为了美观重构大片代码。 Stop conditions(什么时候必须停手) - 要引入新依赖或做大版本升级。 - 改动超过 5 个文件。 - 连续 2 次排错失败找不到原因。 
 Context(背景) (说明:仓库定位 / 相关模块 / 限制条件) Goal(目标) (一句话说清你想要什么效果) Acceptance criteria(验收标准) - (使用什么命令可以校验结果) Constraints(约束) - 不泄露 secrets - 最小化改动 Delivery(必须交付) 1) 计划 2) 代码改动 3) 关键 diff 4) 验证通过的输出 
  • 绝不往 stdout 写日志(调试信息走 stderr)。
  • 先在本地跑通,再对接远端或外部 API。
  • 每个 tool 都要定义清楚:入参类型(schema)、返回结构、错误处理、超时限制。
  • 明确读写范围:它能触及的目录有哪些,是否有被限制在子目录中。
  • 写操作尽量做到多次调用不产生副作用。
  • 通讯走 HTTPS
  • redirect URI 严格校验
  • Token 走 Authorization header(不放 query string)
  • 配置 PKCE
  • 按标准走 metadata discovery(.well-known/oauth-authorization-server

见前一篇

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

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

GPT plus 代充 只需 145 

每条带时间戳、耗时和 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} 

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

小讯
上一篇 2026-03-20 07:19
下一篇 2026-03-20 07:17

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/244684.html