企业官网建设流程全解析

去年我还在给团队演示一个能自动查库存、自动发邮件的 MCP Demo，所有人都觉得“这不就成了吗”。真正把基于 MCP 协议的 AI 自动化中台推到线上环境之后，第一个星期我就被权限、稳定性、重复执行这些问题锤得满头包。MCP（Model Context Protocol）确实把 AI 接入工具的协议标准化了，但“模型能调工具”和“中台能可靠地、安全地让模型调工具”之间，隔着生产环境的一整层工程。这篇文章不聊概念,只聊我从一个玩具级 MCP 脚本演进到内部自动化中台的完整过程，包括架构选型、权限沙箱设计、核心实操，以及那些文档里永远不会写的坑。

如果你正准备把 MCP 从本地实验推到真实业务，或者你在设计 AI Agent 平台却被“工具该不该放开给模型”折磨过，这篇应该能帮你少走几个月的弯路。

1. 为什么 Toy Demo 走不到生产：先拆解三个根本矛盾

1.1 协议通了，边界没通

MCP 协议解决的核心问题，是让 LLM 以一个标准方式去发现和调用外部工具。它把整个链路抽象成 Host（模型宿主）、Client（协议客户端）、Server（工具提供方）三层，用 JSON-RPC 2.0 做消息格式，工具通过tools/list暴露给模型，通过tools/call被调用。demo 里你搭一个 Server，暴露两三个工具，让模型在本地跑通，看着非常优雅。

但到了生产环境，协议通的只是“调用”这条线，业务边界、权限边界、数据边界是另一套东西。比如一个简单的“查询订单”工具，本地 demo 里一把数据库连接查完就结束，但在公司里你可能要接权限系统、要判断请求方属于哪个部门、要过滤敏感字段、要记录谁在什么时间查了谁的订单。这些都不是 MCP 协议替你处理的事，协议只管把参数传进来、把结果传回去。

所以我把 MCP 理解成“自动化中台的 API 总线”，而不是“自动化中台本身”。总线解决了传输格式和工具发现的问题，但总线上跑的业务流、权限流、审计流，全部得你自己建。这个认知如果不先摆正，后面所有设计都会跑偏。

1.2 模型会撒谎，也会犯错

LLM 调用工具最大的特点是：它会一本正经地构造参数，然后自信地执行。比如让它调用“发送邮件”，它可能把收件人字段填成上一次对话里出现的名字，或者根据模糊记忆拼出一个不存在的邮箱地址。本地 demo 里你手工验证一次结果，发现邮件发到测试地址，无所谓。生产环境这就是事故。

模型不是可靠的状态机，它是一个“概率模拟器”。这意味着你设计工具接口时必须假设：参数可能缺失、参数类型可能错误、参数语义可能离谱、同一个操作可能被重复请求。所有在校验和防御上的偷懒，最终都会变成线上告警。

我在设计生产级工具时，强制给自己加了一条铁律：模型给的参数永远是不可信输入，服务端必须二次校验，并且对副作用操作做幂等处理。这个原则贯穿了后面所有的架构设计。

1.3 单机行云流水，多用户鸡飞狗跳

本地 demo 只有一个用户，也就是你自己。你的 MCP Server 没有并发，没有资源争抢，没有调用频率限制，没有数据隔离。但中台一上线，十个业务方接入，几十个工具被同时调用，就会出现一系列本地永远发现不了的问题。

举个真实例子：我们的一个数据导出工具，单个用户调用时 200ms 返回。但五个用户同时导出大数据集时，数据库连接池被打满，其他业务全被拖死。本地 demo 里你永远不会压出这种问题，因为根本没有并发。生产级中台要求你在设计第一天就考虑并发隔离、资源配额、限流、降级。这跟写脚本的思维完全不同。

2. 中台架构演进：从 All-in-One 脚本到分层服务

2.1 第一代：演示脚本，能跑但不可控

我最早做的“MCP 中台”本质上就是一个 Python 脚本。所有工具逻辑写在一个文件里，模型通过本地 Transport 调用，工具直接操作数据库、直接发 HTTP 请求。这个阶段跑通 demo 没问题，但问题在于：工具逻辑和调用逻辑耦合在同一个进程里，没有任何隔离手段。

比如“查询库存”和“修改库存”两个工具，可能就是两个函数，权限上没有任何区分。模型想调用哪个就调用哪个，参数合法就直接执行。开发阶段我能用肉眼盯着日志，生产上这种裸奔方式完全不可接受。

还有一个隐蔽问题：工具之间共享全局状态。某个工具改了一个全局变量，另一个工具读到的是被污染的数据，排查起来非常痛苦。第一代架构给我最大的教训是：工程化不是给代码加注释，而是把系统中可变的部分和不可变的部分分开，把有副作用的操作和无副作用的操作分开。

2.2 第二代：单体 HTTP 网关，把“调用”变成“权限”

第二版我把所有工具封装成了 HTTP 接口，外面套了一层网关。模型不再直接连 MCP Server，而是通过网关转发。这个改造的核心收获是：有了一个集中入口，可以在网关层做身份认证、参数校验和基础限流。

但做得还不够透。因为工具逻辑还是和业务数据库直连，网关只挡了“谁在调”，没管“能调什么”。比如一个员工账号和一个管理员账号，都能调“删除用户”这个工具，网关一律放行。我意识到：把工具暴露给模型之前，需要先想清楚工具的“权限语义”——每个工具属于哪个权限级别、谁能调、调了之后能碰哪些数据。

这一阶段的另外一个大问题是：工具越来越多之后，网关路由表和鉴权规则开始膨胀，每加一个工具就要改一遍网关配置。我意识到需要一套更标准的方案，让工具自己声明权限需求，而不是网关注册时硬编码。

2.3 第三代：MCP Server 集群 + 网关 + 沙箱执行层

第三代架构才真正有了“中台”的样子，核心思想是分层和解耦：

• 接入层（Gateway）：负责身份认证、权限校验、限流、审计日志。所有 MCP Client 的连接都走这里。
• 协议层（MCP Server Cluster）：负责工具发现、工具调用路由、协议转换。每个 Server 只做协议翻译，不直接碰业务数据源。
• 执行层（Tool Execution Sandbox）：真正的工具逻辑在这里执行。每个工具运行在受限环境中，通过网络策略、系统权限、数据库账号三层隔离。
• 数据层：统一的数据访问服务，工具不直接连库，而是通过数据服务按需取数。

协议层和执行层分离是我觉得整个改造里最关键的一步。以前工具函数直接连数据库，现在工具逻辑被封装成标准接口，部署在沙箱容器里，MCP Server 只负责把模型的请求翻译成对沙箱内部接口的调用。这样做的好处是：工具的爆炸半径被限制住了。就算某个工具有漏洞，或者模型构造了恶意参数，最坏情况也只是影响沙箱内部，不会直接打穿数据库。

如果你也要做类似的演进，我的建议是别一上来就搞微服务，先把“调用链”拆成“接入层 / 协议层 / 执行层”三层，每一层独立部署，再逐步细化。这个演进路径比直接上微服务稳妥得多。

3. 权限沙箱：生产级中台的生命线

3.1 三层权限模型：从用户到工具的最小授权链

权限沙箱是我在这次改造中投入精力最多的部分，也是踩坑最多的地方。生产环境里你不可能让模型拿着管理员凭据随便调工具，必须设计一套可配置、可审计的权限链。我的方案是三层模型：

第一层：用户身份层。每个发起请求的人或服务，先经过统一身份认证，拿到一个身份令牌。这个令牌不携带任何工具权限，只代表“是谁在发起请求”。

第二层：项目授权层。每个业务项目是一个授权单元，项目管理员配置这个项目可以用哪些工具。比如“订单查询”项目只能使用查询类工具，不能使用“删除订单”工具。这个配置存在权限中心，运行时由网关动态加载。

第三层：工具级约束层。每个工具本身声明它需要的执行权限级别：只读级别、写操作级别、危险操作级别。只读级别直接放行；写操作级别需要校验目标资源是否属于当前用户/项目；危险操作（删除、批量修改、发送外部消息）则强制人工审批。

实际落地时我用了非常朴素的一张权限表，核心字段如下：

授权原则只有一个：默认拒绝，白名单放行。所有工具默认不可用，只有显式授权后才出现在对应项目的工具列表里。这个原则看起来简单，但它避免了“漏配一个就裸奔”的问题。

3.2 敏感工具的隔离执行与审批流

对于有副作用的高危工具，光靠权限表还不够。实操中我采用了两段式设计：写工具一律不直接执行，而是先创建“操作意图”，由中台去执行。

举个例子：让模型“删除某个测试环境的临时数据”，模型调用工具后返回的不是“删除结果”，而是一个“任务已创建，等待审批”的状态。后台有一个审批人可以点同意或拒绝，只有同意后，任务才会真正执行。审批环节不依赖 LLM 判断，永远由真人控制。

这看起来是多了一步流程，但在生产环境里非常值得。模型可能因为上下文理解偏差，把一个正常的“清理临时表”误判成“清空正式表”。有了审批拦截，这类风险至少能兜底。我在审批流里还加了一个机制：审批超时自动拒绝，而不是自动跳过。别问我为什么，问就是我见过超时自动通过导致的事故。

另外，危险工具的执行环境要单独隔离。我做法是：危险工具跑在独立的容器里，网络层面只能访问指定内网服务，其他地址一律不通。容器内没有业务数据库的完整凭据，而是通过一个代理 API 按需取数，代理层还会做一次数据范围的二次校验。

3.3 参数校验与数据脱敏：防的不是模型，是“边界”

权限沙箱还有一个容易被忽略的维度：参数校验和数据脱敏。模型给的参数，即使它完全按照指令来，也不代表参数是安全的。比如“查询用户详情”这个工具，模型可能从一个项目上下文里拿了一个 user_id 传进来，这个 user_id 可能属于另一个项目下的用户。如果你只校验了“工具有权限被调用”，没有校验“参数资源属于调用方”，越权就发生了。

我踩到过一次真实越权问题：一个内部查询工具，传了 user_id 就能查任意用户的资料。测试环境没人发现，上线后运维顺手用管理员账号跑了一遍，才发现可以查到全量用户信息。修复方案不是给工具加 if 判断，而是在工具执行前的参数解析阶段，强制增加“数据所有权校验”。也就是说，工具逻辑里永远不能直接信任模型传入的资源 ID，必须根据当前请求身份重新推导出可访问的资源范围，再用范围过滤 ID。

数据脱敏方面，我常用的策略是“按需取字段”。比如一个“查询订单工具”，模型其实只需要订单号、状态和金额三个字段，但数据库里有收货地址、手机号。工具返回时只返回模型需要的字段，而不是把整条数据库记录序列化扔回去。这不仅是隐私合规要求，也能显著减少 token 消耗，一举两得。

4. 核心实操：把 MCP Server 打磨成能上生产的服务

4.1 工具定义规范：命名、Schema 与描述词的工程化

MCP 的工具发现机制依赖tools/list接口，模型看到的只有工具名、描述和输入 Schema。工具的“可理解性”直接决定了模型能不能正确使用它。我在几百次调试之后总结了一套工具定义规范：

命名必须带业务域前缀。比如order.query_status而不是query_status。MCP 协议支持工具名任意字符串，但带命名空间可以大幅降低模型混淆同名工具的概率。实测中，不带前缀时模型偶尔会把“查询用户订单”和“查询用户信息”搞混，加了order.和profile.前缀后这类错误明显减少。

description 要告诉模型“什么时候别用”。光写“查询订单状态”是不够的，我通常在描述里补充：“此工具只能查询已支付订单，不适用于退款查询，退款查询请调用refund.query_progress”。这一步非常有效。模型的工具选择本质上是一个语义匹配任务，描述里写清楚边界，匹配准确率会明显提升。

inputSchema 要严格设置必填项和类型。我吃过一个大亏：一个新增订单的工具，参数里忘记把product_id标成必填，模型某次调用时漏了这个字段，服务端按默认值 0 处理，结果创建了一批脏数据。后来我把所有工具的 Schema 都做了严格校验，服务端判空直接报错，不再使用任何“智能默认值”。

下面是我实际用过的工具定义示例，结构是 MCP SDK 常见的 dict 描述方式：

tool_definition = { "name": "order.query_status", "description": "按订单号查询订单当前状态，仅适用于已支付订单。如需查询退款进度，使用 refund.query_progress。", "inputSchema": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，格式如 ORD20250101XXXX" } }, "required": ["order_id"] } }

4.2 超时、幂等与并发控制

模型调用工具有一个特点：它可能因为生成中断而重复发起同一个工具请求，也可能多个 Agent 任务并发调用同一个写工具。如果不做超时和幂等控制，生产环境会出现重复下单、重复发送通知这类事故。我用三个机制解决：

超时控制。MCP 的tools/call响应如果长期不返回，模型侧会感到困惑甚至继续重试。我统一为每个工具设置默认超时时间，交互类工具控制在 10 秒以内，查询类工具 15 秒，写操作类工具因为可能涉及异步审批，直接返回“任务已受理”，不让模型等最终结果。这个“立即回执，异步处理”的模式强烈推荐。

幂等键。对写操作工具，我在入参里强制要求一个request_id字段，由调用方生成。服务端维护一张去重表，同一个request_id只执行一次，重复请求直接返回第一次的结果。这样即使模型因为网络超时重试了几遍，也不会造成重复写。

并发限制。每个工具在网关层配置最大并发数。比如数据库导出的工具，单实例最多支持 3 个并发，超过后排队等待，排队超过 30 秒直接拒绝。我见过最惨的事故不是工具慢，而是工具调用方一次性发来 50 个并发请求，把下游系统打挂。并发限制虽然让单次请求可能变慢，但能保护整个中台的可用性。

这里也提醒一个小细节：不要把超时时间设得太“宽容”。有一次我把超时调到 60 秒，结果下游数据库锁死 40 秒，这段时间里所有查询全部堆积在连接池里等锁。后来我调回 10 秒，虽然个别慢查询会失败，但至少不影响全局。中台设计要的是“快速失败”，不是“拼命等待”。

4.3 审计、链路追踪与可观测性

生产环境里，AI 工具调用不可能每次都复现，出了问题只能查日志。所以审计日志就是中台的“黑匣子”，我强烈建议从第一天就把所有请求链路记录下来。我的审计日志至少包含以下信息：

• 用户 ID / 项目 ID / 身份令牌
• 调用的工具名和入参（入参会去掉敏感字段）
• 执行的耗时和结果摘要
• 是否通过审批、审批人是谁
• 关联的 Trace ID，方便查询完整调用链

日志存储上我建议写到独立的审计库里，和业务数据分开。除了审计，可观测性也很关键。我给每个工具挂了三个指标：调用次数、失败次数、耗时分位数。这三个指标配合告警规则，能快速发现“某个工具突然变慢”或“失败率激增”这类问题。

有一些现成的 Prometheus 客户端库可以直接接 MCP Server，但需要注意：MCP Server 内部不要直接暴露业务指标，而是把业务指标和系统指标分开暴露。实测中这样做可以避免云平台抓取指标时把敏感的业务调用信息带出去。

5. 实战踩坑实录：我替你们踩过的 7 个坑

5.1 上下文爆炸：再好的 Server 也扛不住无节制返回

最早调试“批量查询订单”工具时，我让工具把 1000 条订单完整返回。结果模型还没开始分析，上下文已经被工具结果撑爆了，后续对话直接退化。MCP 工具返回的数据量是会直接塞进模型上下文的，工具返回值必须遵循最小够用原则。

后来的实践是：工具返回前先做摘要，只返回分页后的部分数据，并且用一句提示告诉模型“如需更多数据，请指定页数重新调用”。这个改变让一次多轮查询任务的 token 消耗下降了大约 60%，还给模型省出了推理空间。

我遇到过最夸张的一次：某个工具把一张十列的表整行返回，模型其实只需要其中两列。后来我在工具实现里明确圈定返回值字段，把五分之四的无用字段全砍掉，问题就消失了。

5.2 工具“二重调用”：幂等键救我一命

有一次线上跑一个“批量给客户发送服务通知”的 Agent 任务，模型可能因为生成过程被打断，连续两次调用了同一个发送工具，结果客户收到两条一模一样的通知。查日志发现两次请求的入参完全相同，只是发出时间差了2秒。

当时我立刻给所有写操作工具加了request_id，服务端用数据库唯一索引做幂等。后来的处理流程变成这样：收到请求 → 查request_id是否已存在 → 存在则直接返回历史结果 → 不存在则执行。加了之后这类“重复执行”问题基本绝迹。

另外要提醒：有的模型在生成工具调用时，会在参数里自动带一个 id 字段，但它并不稳定。所以request_id最好由网关在收到模型请求时自动生成，而不是依赖模型自己传。我给网关加了一层包装，识别不到合法request_id就自动生成一个，再把参数传给执行层。

5.3 越权漏洞：参数白名单挡不住恶意意图

权限沙箱不是配好权限表就完事了，它必须在运行时动态校验。我差点因为只做静态权限配置而漏掉一个大洞。当时有个工具的入参是文件路径，我们配置了项目权限后觉得万事大吉。但某次测试发现，模型可以从上下文里读出另一个项目的文件路径，把这个路径作为参数传进来，工具直接读取并返回了。

这个问题的本质是：权限表只管“这个人能不能调这个工具”，没管“传入的资源是否属于这个人”。修复方式是在工具执行前，用身份令牌重新解析资源归属。比如文件路径必须包含当前项目目录前缀，订单 ID 必须属于当前用户，查询范围直接由服务端代码限定，而不是相信模型传什么就查什么。

如果你也要做生产级 MCP 中台，我把这条经验放在最前面：模型构造的参数，一律按“不可信输入”处理。不管是工具名、参数值、资源 ID，全部要过服务端校验。

5.4 副作用不可回滚：把写操作改成异步任务

“写操作失败可以重试，但不能当作没发生”。这个教训来自一次配置错误。当时我们的“修改库存”工具是同步执行：模型调用后直接 UPDATE 数据库。某一次模型对同一个 SKU 连续发了两个修改请求，先是“库存 -10”，后是“库存 -5”，服务端都执行了。结果业务方说实际只该扣 5 件，前面那 10 件不该扣。回滚数据库时才发现没有快照，只能靠人肉修复。

自此之后，所有涉及账目、库存、发送通知等有副作用的工具，全部改成“提交操作意图 → 审批 → 异步执行 → 记录回滚快照”模式。写操作工具返回给模型的只是一个任务号，模型再去查任务状态。这样即使一次操作写错，也有完整快照可以追溯，甚至可以直接执行反向操作恢复。

这个模式在设计 MCP 工具时会让流程变重一些，但对生产系统来说，可控性远比便利性重要。

5.5 SSE 与 Streamable HTTP：传输层的坑

MCP 的传输层有几种模式：本地 stdio、SSE、Streamable HTTP。我在本地调试用的是 stdio，很方便。但一旦部署成多客户端共享的 Server，SSE 和 Streamable HTTP 之间的差异就显现了。

SSE 模式是单向的，客户端连上来之后，服务器推送事件。但工具调用是请求-响应模式，如果连接断开或者代理超时，回调消息可能丢失。Streamable HTTP 用标准 HTTP 长连接，对网关、负载均衡更友好。我最初用 SSE 部署在公司内网，频繁出现“模型调了工具但收不到结果”的诡异问题。切到 Streamable HTTP 后，配合标准 HTTP 超时和重试机制，问题消失了。

如果你的 MCP Server 要放到云环境或公司 L7 网关后面，我强烈建议直接用 Streamable HTTP。SSE 在复杂网络环境下调试成本太高，而且一旦中间有代理，连接保持是个暗坑。

5.6 多客户端共享状态：Server 其实是“无状态”的

第二个传输层的坑：MCP Server 本质上应该是无状态的。早期我在 Server 内存里保存了“当前用户会话”这种全局变量，结果发现两个客户端同时连上来时，状态互相覆盖。一个用户查库存，另一个用户也查库存，两个请求拿到的却是同一条上下文。

实际上 MCP 协议本身并没有定义服务端会话状态的管理方式，所有状态都应该放在外部存储或者请求参数里。我后来把“用户身份”统一放进了请求头，把“临时变量”放进了外部 Redis，Server 进程变成纯转发和逻辑计算，不再维护任何可变状态。这让部署和横向扩容都变得特别简单。

如果你在做多客户端共享 MCP Server，请记住：不要在 Server 进程里保存任何全局变更数据，否则并发一高就会出各种随机故障。

5.7 工具调用频控与成本：一次 Agent 任务能烧掉几十次调用

最后一个坑是成本问题。本地 demo 你调几次工具无感，生产上你按 token 计费，一次复杂 Agent 任务可能触发几十次工具调用，其中一半是“因为上下文不够转而去翻历史记录”的无效调用。

我们的策略是分三层：第一层是网关层设置单用户每分钟工具调用上限；第二层是工具返回结果做缓存，对相同参数的只读工具请求直接命中缓存；第三层是 Agent 编排时减少“试探性调用”。模型不知道工具功能时，倾向于先调一次试试看，这很费 token。通过把工具描述写得更精确，这类试探次数明显减少。

另外，我在日志里统计了工具调用分布，发现耗 token 最多的是“查询历史记录”类工具。后来给这些工具加了时间范围参数，只返回最近 30 分钟的数据，大部分场景已经够用。

6. 稳定性兜底：熔断、压测与容量规划

6.1 熔断、降级与优雅关闭

中台服务只要上了生产，就一定会遇到依赖方故障。比如某个数据服务的慢查询导致工具集体超时。这时候如果网关还继续把请求转发给执行层，故障会迅速扩散到所有业务。

我给每个工具实现了一个轻量熔断器：连续错误率达到阈值（比如 50%）时，不再真实调用工具，直接返回一个“工具当前暂不可用，请稍后重试”的降级结果。模型的应对一般是告诉用户“系统繁忙”或等待下次调用，不会崩溃。等错误率恢复后，熔断器自动半开，放一小部分流量试探下游是否恢复。

优雅关闭也值得专门做。MCP Server 在滚动发布时，如果直接 kill 掉进程，正在执行中的工具调用会中断，可能留下半执行状态。我给服务加了一个 shutdown 钩子：收到退出信号后，先停止接收新请求，等待当前请求最多完成 30 秒，再退出进程。实测滚动发布几乎没有影响过正在跑的任务。

6.2 压测与容量估算：别拿 Demo 数据骗自己

上线前我做了一次比较认真的压测，用的工具是 Playwright 模拟 MCP Client 连续调用。压测结果让我很意外：单实例 Server 在不做并发限制的情况下，150 个并发请求就能让大量工具超时；但加上限流和连接池优化后，同样配置可以扛住 500 个并发。

所以容量规划不能只看 Server 本身的性能，要看整条链路的瓶颈。比如数据库连接池、下游 HTTP 服务的吞吐，这才是真正卡脖子的地方。另外一点，压测时一定要覆盖“失败场景”，比如强制让一个工具 100% 失败，观察网关的降级和熔断是否生效。只压“成功路径”会让你误判系统很健壮，真实故障一到就原形毕露。

我建议的容量规划方法是：以高峰期请求量的 2-3 倍为目标做压测，同时关注 P99 延迟。MCP 工具调用如果超过 30 秒，模型很容易着急重试，导致负载叠罗汉。尽量保证大部分工具调用的耗时在 10 秒以内，这样重试概率会低很多。

7. 写在最后：个人几点体会

整个改造走下来，我自己最深的感受是：前期方案里“要把架构做得多复杂”从来都不是重点，真正的重点永远是能不能在权限边界、数据边界、故障边界上忍住不做模糊处理。一个玩具 Demo 和一个能用的中台，最大的分界线不是技术栈牛逼程度，而是你面对“工具被越权调用”“重复执行”“上下文被撑爆”“调用方滥用”这些具体问题时，是否有一套成体系的防御手段。

我还在坚持做的几件事，如果你也想改造自己的自动化中台，可以参考：第一，每个新接入的工具必须先填一份“工具健康度检查表”，把读写类型、数据敏感度、超时目标、是否有副作用这几项写清楚，再决定它能不能进入工具池。第二，没有走过一遍“哑客户端”全链路的工具，不允许接入模型。所谓哑客户端，就是先用固定参数把工具从调用到返回完整打一遍，确认服务端校验、幂等、审计都正常，再让模型接手。第三，但凡有副作用的功能，坚持做成“提交意图 + 异步执行 + 回执查询”模式，我后来越发觉得这是一个能救命的范式。

最后再分享一个我用得比较顺手的小技巧：MCP Server 里给模型返回结果时，可以在文本前加一句机器指令，比如“如果结果为空，请直接告知用户暂无数据，不要尝试再次查询”。这种“结果内嵌提示”对控制模型的重复调用非常有效，算是花小钱办大事。

如果这篇能帮你少踩几个坑，哪怕只有一点，这篇长文也算没白写。后续如果你们也在做 MCP 中台改造，遇到有意思的问题，欢迎回来一起聊聊。