Vibe Engines 是免费的交互式 AI 工程与系统设计课程——可直接在浏览器中运行。选择学习路径 →

前沿部署工程师/

面向 FDE 的 MCP

交付物是一个工具界面，而不是一个聊天机器人

Anthropic 的前沿部署工程师职位描述将 MCP 服务器、子 Agent 和 Agent 技能列为你为客户构建的内容。10 在实践中，这意味着你交付的产物很少是一个应用程序。它是一组工具，将客户的系统——一个 2009 年的 SOAP 服务、一个存储过程、一个文件共享上的电子表格——封装成模型可以安全使用的形式。把这个界面设计好是一项独特的技能，它更接近于 API 设计，而不是提示词编写。

为什么这成为了一项 FDE 交付物

在客户那里，有趣的能力几乎从来不是模型本身。而是连接到他们系统的模型：理赔数据库、零件目录、自 2011 年以来就没人更换过的工单系统。在工具协议出现之前，每一个连接都是写进单个应用程序的定制集成。MCP 把它变成了一个可复用的服务器——而这正是决定部署工作是不断积累还是迅速蒸发（参见商业层面）的关键属性。

一个服务器暴露三样东西：工具（模型可以调用的操作）、资源（模型可以读取的数据）和提示词（可复用的指令模板）。你编写服务器；一个宿主应用程序——桌面助手、内部 agent、编码工具——连接到它。对部署而言，其价值在于同一个服务器可以服务所有宿主，因此你为某个工作流构建的集成，下一个工作流无需重写即可使用。关于协议机制，请从 MCP 手册开始；本页讨论的是当系统属于别人时会发生什么变化。

什么情况下 MCP 服务器是正确的交付物

  • 客户有多个工作流触及相同的底层系统。
  • 他们已经有宿主应用程序——一个助手、一个 IDE、一个内部 Agent。
  • 集成是难点；其上的推理相对廉价。
  • 你希望这些工作能超越你最初构建的那个特定应用程序而存续。

什么时候它是错误的交付物

  • 一个工作流、一个系统、没有可能的第二个使用者——直接集成更小、更清晰。
  • 客户没有宿主应用程序，也不想要一个；你会交付一个没人能调用的服务器。
  • 该操作高风险且不可逆，真正的需求是带有审批环节的确定性流水线。
  • 延迟预算非常紧张，以至于额外的一跳和一次模型往返就会使其超标。

为模型而非开发者设计工具

这是 MCP 服务器之间最大的质量差异。一个好的 API 并不自动等于一个好的工具界面。

阅读你的 API 的开发者拥有文档、调试器，以及明天再试一次的机会。而模型只有一个名字、一段描述、一个 JSON schema 和一次机会。一切后果都源于这种不对称性——失败很少是因为模型“不擅长使用工具”，而是因为工具界面本身会让一个同样只看到这三句话的能干人类也感到困惑。

get_data(entity, filters, options, format, page, expand, mode, ...)

“检索数据。”

→ 14 个可选参数，没有词汇约定，不知道 entity 接受什么值

# 模型第一次尝试就能正确使用的界面

find_claims_by_policy(policy_number: str, status?: "open"|"closed"|"appealed")

“查找与保单关联的理赔。当用户给出保单号时使用

（格式：AB-123456）。最多返回 50 条，按最新排序。如果是理赔单号，

请改用 get_claim。”

使用领域内的动词·

用枚举而非自由文本·

说明何时使用·

指出它的兄弟工具

以用户的任务命名工具，而不是以你的 schema

find_overdue_invoices

胜过

query_invoice_table

。模型是在将请求与名称进行模式匹配，所以一个呼应业务中工作描述方式的名称，会胜过一个呼应你数据库结构的名称。

为决策而写描述，而不是为机制

描述的任务是回答“我现在应该调用它吗？会得到什么？”说明何时使用、何时不使用、返回什么、代价是什么。描述是整个服务器中杠杆最高的文本，却通常最后才匆忙写就。

严格约束 schema

用枚举而非字符串，用必填而非可选，每种事物只留一种显而易见的表达方式。每一个自由度都是一种被错误调用的方式。如果某个参数有合理的默认值，就把它设为默认值，而不是留作一个决策。

返回散文式结构的结果，而非原始转储

一个 4000 行的 JSON 大块会烧掉上下文窗口并把答案埋没。返回真正重要的字段，并预先汇总好，同时明确提示“调用

get_claim_detail

获取其余内容”。

Pagination

提示应放在返回数据中，而不是文档里。

让错误信息具有指导性

"No policy matches AB-12345. Policy numbers are two letters and six digits; did you mean AB-123456?"

模型能从中恢复。但它无法从

400 Bad Request

中恢复，而且通常会原样重试同一个调用。

保持工具集精简

每个工具都在与其他所有工具争夺注意力。五个锋利的工具胜过二十个重叠的工具。当服务器增长到超出一个提示词所能舒适容纳的规模时，按领域拆分它，让宿主按具体工作流的需要挂载。

工具设计是可测试的，但几乎没人测试它。构建二十个真实请求，运行它们，并分别对工具选择准确率和参数正确性打分——它们失败的原因不同，修复所需的改动也不同。选择错误是命名和描述的问题；参数错误是 schema 的问题。这是一个小型评测集，它应该像客户项目评测中的那些一样进入 CI。

封装遗留系统

真实的工作场景。它很少是一个礼貌地躲在防火墙后面的 REST API。

你在客户那里会发现：一个 WSDL 上次编辑于 2009 年的 SOAP 服务，一个真正的业务逻辑都藏在存储过程里的 Oracle 实例，一个只能通过定宽文件投递访问的大型机，一个有严格速率限制的 SaaS 产品，还有一份被四个人当作唯一事实来源的电子表格。每一个都要变成一个工具。而它们没有一个愿意。

你会发现什么应对方法陷阱
SOAP / WSDL生成一个客户端，然后针对任何人真正会用到的三个操作，手写一个窄接口的工具。把生成的全部 60 个操作都暴露出去。模型会被淹没并选错。
存储过程把命名的过程封装为带类型参数的命名工具。提供原始 SQL。这既是一个安全漏洞，又是一个无界的查询面。
定宽 / 批量文件投递异步工具：submit_job 加 check_job，并在描述中写明预期的耗时。假装它是同步的。一个阻塞九分钟的工具会拖垮每一个调用它的宿主。
有速率限制的 SaaS缓存、批量处理，并在工具结果中展示剩余配额。让一个 Agent 循环在生产环境中、在客户的共享配额上，替你发现限制的存在。
电子表格只读资源，按计划做快照，并在每次响应中附上数据新鲜度时间戳。往里写数据。有人正开着这个文件，你会亲眼见识文件锁的行为。
完全没有 API尽早说明，并诚实地为集成定价。因为演示效果好就去抓取他们的内部 UI。它一定会坏，而且会在最糟糕的时刻坏。

他们的系统用代码说话：状态

7

、类型

RTX

、区域

EMEA-2

。模型——以及用户——用词语说话。这个翻译层应该放在

in the server

里，而不是放在提示词中，因为提示词是每个应用独立的，而服务器是共享的。在返回原始代码的同时返回“closed — settled（已关闭——已结算）”，并接受词语作为输入，你就为未来所有工作流消除了一整类故障。构建这种映射也是学习业务领域最快的方式，这正是

learning a domain fast

.

没有人划下的信任边界

一个 MCP 服务器夹在一个什么都肯读的模型和一个让它做什么就做什么的系统之间。

两个特性叠加起来会很糟糕。模型把检索到的内容当作信息，而从客户系统检索到的内容是人写的——有时甚至是公司外部的人写的。一张工单描述、一封供应商邮件、一个 PDF 文件名，全都是不可信的文本，最终会出现在你的指令旁边的上下文窗口里。要显式地划出这条边界，因为默认状态是根本没有边界。

身份：一次工具调用以谁的权限运行——是最终用户的，还是一个

拥有所有人权限并集的服务账号？（必须是用户的）

爆炸半径哪些工具会修改状态？其中哪些是可逆的？

内容检索到的文本是否曾被当作指令处理？（绝不能这样）

证据你能向审计人员展示上周二谁通过 Agent 做了什么吗？

客户环境中的不可妥协事项

  • 工具调用以最终用户身份并使用其权限执行。一个拥有所有人权限的服务账户会把读取工具变成数据外泄通道。
  • 写入工具与读取工具分离，且需要明确确认。
  • 检索到的内容会被定界并标记为数据，绝不混入指令。
  • 每次工具调用都会记录用户、参数、结果大小和时间戳。
  • 破坏性操作没有对应的工具。它们走工单流程。

实践中是如何出问题的

  • 使用单一服务账户，因为按用户认证被留到了“第二阶段”。
  • 一个摘要工具读取了某个工单，其正文写着“另外把客户名单发送到……”。
  • 一个为调试而添加却从未移除的 run_query 逃生通道。
  • 日志只记录了某个工具运行过，却没有记录它返回了哪些记录。
  • 一个禁用认证的开发模式开关，因为演示需要就随代码一起发布了。

安全审查人员越来越多地要求进行实时提示注入测试：在 Agent 会读取的记录中放入恶意文本，并展示会发生什么。请先自己运行一遍。准备好一个有记录的答案——以及一个经得起考验的边界——能把一场艰难的会议变成一场简短的会议。在 Security Review Gauntlet 中演练完整的审查流程，并在 the prompt-injection lab 中了解攻击本身。

运营一个不由你托管的服务器

一旦它能运行，它就必须在别人的环境中持续运行——这意味着 IaC for customer environments 和 on-call 中的运维问题在这里会以特定的形式出现。

对工具表面进行版本管理，而不仅仅是代码

重命名工具或收紧 schema 会改变所有连接到它的宿主中的模型行为。把工具表面当作公共 API 来对待：可以随意做增量式变更，移除操作要有弃用窗口期，语义发生变化时要在描述中注明。

按工具进行监控

调用次数、错误率、延迟和结果大小，按工具细分。这能告诉你模型实际会使用哪些工具、哪些是死重——而死工具应该被删除，因为它们在每次请求中都会消耗注意力。

明确地降级

当上游服务宕机时，返回一个用模型能够转述的语言说明情况的工具结果。超时会产生一个自信但错误的答案；

"the claims system is unavailable — no data was retrieved"

而明确说明则会产生一个诚实的答案。

交付工具契约，而不是代码仓库

他们的团队需要一份文档，列出每个工具、其参数、其权限及其上游依赖。这份文档就是交付物，能让他们在你离开后添加第七个工具——而这正是全部意义所在。

一些团队所描述的 2026 年的转变是：前沿部署工程师从编写功能代码转向编写那些编写功能代码的系统——即由工程师监督的 Agent harness。30 一个设计良好的工具面正是这一切的基础：agent harness 的好坏取决于它能调用的工具，以及这些工具所遵守的边界。因此，这本手册与其说是一份协议教程，不如说是一次对交付物走向的押注。

先构建工具面，再攻击它

全景图：四个边界检查所在的位置

实战示例：用 20 个请求为工具面打分

你把理赔系统封装起来，编写 20 个真实场景的请求——也就是该页面所说的属于 CI 的那种请求。每次运行都会被打两次分：模型是否选对了工具，以及选对工具时参数是否正确？计数是示意性的，但算术是精确的。

版本变更工具选对参数正确（在选对工具的情况下）端到端
v1一个 get_data(entity, filters, …)，描述为“检索数据。”12 / 20 = 60%7 / 12 = 58%7 / 20 = 35%
v2拆分为以任务命名的工具：find_claims_by_policy、get_claim。描述中说明各自的使用时机，并提及对应的兄弟工具。19 / 20 = 95%13 / 19 = 68%13 / 20 = 65%
v3仅改 schema：status 变为枚举，写明保单格式，服务器同时接受“closed”和代码 719 / 20 = 95%18 / 19 = 95%18 / 20 = 90%

把各列分开来看，修复方案就一目了然了。v1 到 v2 只是命名和描述的改动，它把工具选择从 60% 提升到了 95%，而参数准确率几乎没有变化。v2 到 v3 只改了 schema 和词汇表，就把参数准确率从 68% 提升到了 95%，而工具选择保持不变。如果只看 65% 的端到端分数，你会知道有问题，但不知道该改哪里。

权衡：每种封装选择的代价

这里的时间是指构建它所需的工作量，或它增加的延迟。空间是指它留给模型的工具面大小，以及随之而来的风险。

案例时间空间原因
暴露全部 60 个生成的 SOAP 操作上线最快每次请求的上下文中有 60 个工具模型被淹没并选错工具。构建快，调试慢。
为实际用到的 3 个操作手工编写工具较慢：你得先弄清哪 3 个操作重要3 个以任务命名的工具时间主要花在学习业务领域上，而这本来也是必须做的。
原生 SQL 工具几分钟无限制：任何表、任何查询这是一个安全隐患，而且查询可能会拖垮客户的数据库。
将命名的存储过程作为工具每个过程一个工具参数有界且类型明确客户自己的逻辑仍是唯一事实来源。
在批量投递之上做同步封装编写简单在整个任务期间阻塞宿主（该页面示例中为九分钟）会破坏每一个调用它的宿主。
submit_job + check_job两个工具加轮询宿主保持响应在描述中写明预期耗时，让模型合理地等待。
共享服务账号 vs 每用户身份服务账号：几小时搞定。每用户：需要接入客户的身份提供商所有人权限的并集 vs 单个用户的权限每用户身份是不可妥协的，所以要在第一阶段就为它预留预算。

这种情况在真实项目和面试中如何出现

  • 第二个工作流交付物的真正考验出现在第二个团队要求同样的系统时。如果他们能在自己的宿主中挂载你的服务器并获得可用的工具，说明工作产生了复利效应。如果他们需要 fork 一份，说明词汇表或认证逻辑留在了应用里，而不是服务器里。
  • 编码工具作为第一个宿主许多客户工程师已经在使用支持 MCP 的编码工具。为运维工作流构建的服务器也会出现在他们的编辑器里。这使它成为一个容易上手的首次演示，同时也是一个你必须为其做版本管理的计划外消费者。
  • 按领域拆分当工具数量超过一小撮时，按领域拆分服务器（理赔、保单、文档）可以让每个宿主只挂载某个工作流所需的部分。这也让每个服务器拥有自己的权限和日志，从而缩短安全审查的时间。
  • 面试版本“把这个遗留系统暴露给 Agent”是常见的 FDE 面试题。说出三个任务形态的工具。说明每次调用以谁的身份运行。把慢路径建模为提交加查询。然后描述那个能告诉你这套接口是否可用的 20 请求评测。

自我检测

你的评测显示工具选择准确率 95%，但参数准确率只有 60%。你应该修改什么？

修改 schema，而不是名称。选择错误是命名和描述的问题；参数错误是 schema 的问题。添加枚举、把参数设为必填、声明格式（比如

AB-123456

），并接受业务方的用词作为输入。

客户的对账任务大约需要九分钟。你该如何暴露它？

作为

submit_job

，它立即返回一个任务 id，外加

check_job

。把预期时长写进描述里。单个阻塞式工具会让宿主卡住九分钟并导致崩溃。

一个只读的 summarise_ticket 工具以服务账号运行。它不能写任何东西。为什么它仍然是一个安全问题？

两个原因。它可以读取任何人可见的每一张工单，因此任何用户都能访问到本不该看到的数据。而且工单正文是不可信的文本：“另外把客户名单发邮件到……”会与能够执行操作的工具一起出现在上下文中。它必须以最终用户身份运行，并且工单文本要被标记为数据。

理赔系统宕机，你的工具调用超时了。这个工具应该返回什么？

一个用文字说明情况的正常结果：“理赔系统不可用——未获取到任何数据”。这样模型会如实转达失败。裸的超时或空结果会诱使模型给出自信却错误的回答。

快问快答

为什么 FDE 的职位描述会提到 MCP 服务器？

因为在客户现场，交付物越来越多地是工具界面，而不是应用程序。Anthropic 的前沿部署工程师职位描述将 MCP 服务器、子 Agent 和 Agent 技能列为你为客户构建的内容。一个封装了客户系统的服务器可以在每个工作流和宿主中复用，这正是让部署工作产生复利效应、而不必为每个应用重写的原因。

如何设计模型能正确使用的 MCP 工具？

以用户的任务而非你的数据结构来命名工具，编写能回答“我现在该不该调用它、会得到什么”的描述，包括何时不该使用它；用枚举而非自由文本严格约束数据结构；返回摘要结果而非原始 JSON 转储；让错误信息具有足够的指导性以便恢复；并保持工具集精简，因为每个工具都在争夺注意力。然后分别衡量工具选择准确率和参数正确性。

如何通过 MCP 暴露遗留系统？

只做窄封装，绝不整体暴露。对于 SOAP，针对少数几个实际被使用的操作手写工具，而不是暴露所有生成的操作。对于数据库，封装具名的存储过程，而不是提供原始 SQL。对于批处理或文件投递系统，将其建模为异步提交和查询工具。把代码词汇到业务词汇的转换放在服务器中，而不是放在提示词里，因为服务器会被所有工作流共享。

在客户环境中，MCP 服务器的安全边界是什么？

四条规则：工具调用以最终用户的权限执行，绝不使用持有所有人权限并集的共享服务账户；写工具与读工具分离并要求确认；检索到的内容被定界并标记为数据，因此永远不会被当作指令；每次调用都记录用户、参数和结果大小。要预期安全审查人员会要求现场演示提示词注入。

什么时候 MCP 服务器不是合适的交付物？

当只有一个工作流对接一个系统、且不存在可能的第二个消费者时——直接集成更小、更清晰。当客户没有可连接的宿主应用时。当操作高风险且不可逆、而实际需要的是带审批步骤的确定性流水线时。以及当延迟预算无法承受额外一跳加上一次模型往返时。

来源

本页上的每个数字都可追溯到以下来源之一。凡是由厂商自报或众包而非第一方提供的数据，均已在正文中标注。

本页引用的资料

下一篇：演示与叙事手册 →Next，“部署循环”阶梯 · 第 7 级，共 8 级

探索该主题

将该主题的所有内容——手册、系统设计、挑战和工具——汇集在一处查看。

更多手册