上一篇已经建立了可复用的操作闭环；本篇把同一套“先限定上下文、再要求证据”的方法推进到MCP 扩展。

一、痛点：先定义任务，再谈工具

讨论MCP 扩展时，最常见的误区是用一次“看起来很聪明”的回答替代工程评估。MCP Server、tools、resources分别擅长不同交互位置，但真正决定收益的是任务边界、上下文质量和反馈速度。一个补全工具在单文件样板代码上很快，不代表它适合跨目录迁移；一个代理能运行命令，也不代表应该直接获得发布权限。选型前先写出输入、允许修改范围、验收命令和失败后的回滚办法，才能比较实际完成时间，而不是比较宣传页上的功能数量。

可复用的任务契约只有四项：目标要描述可观察行为；范围列出允许读写的目录；约束写清兼容版本、依赖和禁止事项；验收给出机器可执行命令。提示词“优化这段代码”没有终点，改成“保持公开 API 不变，把重复查询合并，并让指定测试通过”才可审查。AI 输出始终是候选补丁，提交者仍对许可证、安全性、性能与业务语义负责。

二、原理：上下文、动作与反馈构成闭环

能力发现、结构化调用、最小权限不是三个孤立技巧。上下文决定模型能看到什么，动作决定它能改变什么，反馈决定它何时停止。上下文过少会猜接口，过多则挤压关键约束并引入冲突；动作权限过大会放大误判；反馈只写“测试失败”又无法定位原因。因此应先提供目录树、入口、相关类型和一条失败证据，再允许最小修改，最后执行格式化、静态检查、单测和差异审查。

核心取舍是“自主程度换审查成本”。低风险、局部、可快速测试的任务可以让代理连续执行；数据库迁移、鉴权、计费和公共 API 变更应先出计划，再逐步批准。把外部系统接入变成有契约的工具层，意味着评估单位不是聊天轮数，而是从问题定义到可信补丁的总周期。若生成十分钟却需要两小时找隐蔽回归，它就是负收益。

把工作拆成发现、授权、调用、审计四个门。每一门都要有证据：文件路径、命令输出、差异摘要或审查结论。下面的独立脚本把门禁转成加权评分；实际项目可把evidence替换为 CI 结果。第三项失败仍可继续探索，但不能把探索结果当成完成品。

fromdataclassesimportdataclass@dataclass(frozen=True)classCheck:name:strweight:intpassed:boolchecks=[("发现",4),("授权",3),("调用",2),("审计",1),]defevaluate(items:list[tuple[str,int]])->tuple[int,list[Check]]:evidence={name:index!=2forindex,(name,_)inenumerate(items)}results=[Check(name=name,weight=weight,passed=evidence[name])forname,weightinitems]score=sum(item.weightforiteminresultsifitem.passed)returnscore,results score,results=evaluate(checks)foriteminresults:state="通过"ifitem.passedelse"阻断"print(f"{item.name}:{state}(+{item.weightifitem.passedelse0})")print(f"总分:{score}/10")print("结论:","可继续"ifscore>=7else"先补证据")

运行输出：

发现: 通过 (+4) 授权: 通过 (+3) 调用: 阻断 (+0) 审计: 通过 (+1) 总分: 8/10 结论: 可继续

三、实现：用一次小任务校准工作方式

MCP 把宿主、客户端与服务器分开：服务器声明 tools、resources 等能力，客户端发现并调用，宿主负责用户界面、权限与上下文编排。resource 更像可读取的上下文，tool 表示可能产生动作的操作；两者不应因为都能返回文本而混用。清晰的 JSON Schema 会减少模型猜参数，也是权限审查的基础。

本地试验先选只读服务器，通过 stdio 连接，并固定可审查的启动命令。配置后先列能力，再调用一个无副作用工具，检查参数、返回值和错误。随后才接写操作，并为删除、发送、发布设置确认。不要安装来源不明且版本漂移的命令；锁定版本、审查依赖、限制环境变量，并只注入该服务器需要的令牌。

把 MCP 当作第三方代码和新的信任边界。工具描述可能影响模型决策，外部 resource 内容也可能包含提示注入。客户端应展示调用目标与参数，服务器校验身份、租户和输入，审计日志记录调用者、工具、结果摘要与时间。敏感返回值做最小化和脱敏，工具报错不要泄露内部密钥。

先选一个三十分钟内人工也能完成的真实任务，例如给解析函数补边界校验。不要从“重构整个系统”开始，因为那样无法区分模型能力、仓库陌生度和需求缺陷。第一轮只让工具解释调用链，并要求逐条引用文件；第二轮要求列出最多三步计划以及每步验证命令；确认计划后才编辑。每次修改限制在一个可描述的意图内，完成后立刻查看 diff，而不是积累几十个文件再审。

下面的独立脚本把本篇的关键决策写成可审查清单。它不访问网络、不依赖第三方包，复制后即可运行；真正接入项目时，可把清单来源替换成配置文件或 CI 结果。重要的是让允许项与阻断项显式出现，而不是让工具在含糊授权中自行猜测。

fromdataclassesimportdataclass@dataclass(frozen=True)classStep:name:strevidence:strallowed:booldefreview(title:str,steps:list[Step])->tuple[bool,list[str]]:lines=[f"流程:{title}"]accepted=Trueforindex,stepinenumerate(steps,start=1):state="通过"ifstep.allowedelse"阻断"lines.append(f"{index}.{step.name}[{step.evidence}] ->{state}")ifnotstep.allowed:accepted=Falselines.append(f"结论:{'可执行'ifacceptedelse'需人工处理阻断项'}")returnaccepted,lines title='MCP 调用授权'raw_steps=[('查询只读工单','read:tickets',True),('读取指定仓库','read:repo',True),('发送客户邮件','send:mail',False),('删除生产数据','admin:db',False)]steps=[Step(name,evidence,allowed)forname,evidence,allowedinraw_steps]accepted,report=review(title,steps)print("\n".join(report))print(f"自动通过:{accepted}")

运行输出：

流程: MCP 调用授权 1. 查询只读工单 [read:tickets] -> 通过 2. 读取指定仓库 [read:repo] -> 通过 3. 发送客户邮件 [send:mail] -> 阻断 4. 删除生产数据 [admin:db] -> 阻断 结论: 需人工处理阻断项 自动通过: False

提示应包含事实而非情绪：“先不要编辑；读取入口及其直接调用者，解释数据流，列出不确定项”比“认真想想”有效。实现阶段再说：“只修改计划中的文件；不新增依赖；完成后运行命令并按文件总结差异”。若工具无法指出引用来源，先缩小问题，不要用更长的自然语言掩盖缺失上下文。

四、踩坑：防止局部正确破坏系统约束

第一类坑是未读 diff 就接受全部修改。模型可能顺手重排格式、升级依赖或改变错误消息，使核心变更淹没在噪声里。第二类坑是把测试通过等同于需求正确：测试可能没有覆盖时区、并发、权限和空值。第三类坑是把密钥、客户数据、生产日志直接贴入对话。正确做法是脱敏、使用合成样本，并遵守组织的数据保留与供应商策略。

还要警惕“上下文腐烂”：长会话中旧假设仍在，代码却已经改变。跨越一个独立子任务就新开会话，用当前 diff、最新错误和未决问题重新建立上下文。规则文件也不应堆成百科全书；高频、稳定、可验证的规则才常驻，偶发流程放入按需提示。遇到同一错误连续两次，停止让 AI 重试，回到最小复现并改变实验变量。

五、验证：以证据包结束，而不是以一句“完成”结束

验收时要求四件产物：变更摘要说明为什么改；测试清单区分实际运行与建议运行；风险清单指出未覆盖边界；回滚说明给出恢复路径。人工审查先看公共接口、数据迁移和权限，再看异常路径，最后看风格。对生成代码做与人工代码相同的 SAST、依赖扫描和评审，不给“AI 写的”特殊通道，也不因它是 AI 而跳过有价值的自动化。

团队或个人可以记录三个轻量指标：首次测试通过率、审查后被删除的生成代码比例、从开始到合并的总时长。连续观察多次同类任务后再调整工具和规则。指标用于发现流程瓶颈，不用于考核个人输入了多少提示词。MCP 扩展真正成熟的标志，是失败能被快速发现、修改可被解释、工具可被替换。

下一篇继续沿用这套证据链，进入团队治理，解决规模扩大后出现的新问题。

参考来源

• modelcontextprotocol.io：相关官方文档
• modelcontextprotocol.io：相关官方文档
• docs.anthropic.com：相关官方文档

👍 觉得有用就点个赞 + 收藏，方便回头查阅；有疑问直接在评论区留言，我看到都会回。

🚀 本文属于《AI 编程工具实战》系列，持续更新，关注不迷路。

📌 文章里的代码都能直接跑。想要可直接 clone 的完整工程 + 配套部署脚本 / 踩坑清单？评论一声或发邮件到cj2664@qq.com，我免费发你。
如果你正好在做类似系统、或有工程化难题想找人做，也欢迎邮件聊一句——我按实际情况评估，能落地的就接单或出方案。评论和邮件都能直接找到我，不用跳别的平台。