让员工使用聊天机器人并不难，真正困难的是让他们把日常流程封装成可复用、可审计、可治理的 Agent。Ben Maraney 分享的实践表明，企业内部推广 Agent 的关键并不是先搭建一套庞大的 AI 平台，而是降低工具接入门槛：用自定义 MCP Server 暴露内部能力，同时允许无代码平台和代码平台并存，并尽早让安全与法务团队参与。
目标也不应只是举办一次培训。两周内让约 200 名团队成员成为 Agent 创建者，意味着组织需要提供一条足够短的路径：员工能发现问题、连接工具、构建原型，并在明确边界内发布给同事使用。
把内部系统变成 Agent 能调用的工具
Agent 真正产生价值，往往不是因为模型“知道得更多”，而是因为它能在授权范围内完成具体动作，例如：
- 查询服务目录、值班信息或运行手册；
- 创建工单并补充上下文；
- 汇总研发指标；
- 检查发布条件；
- 从经过批准的数据源读取业务信息。
MCP（Model Context Protocol）适合充当这层标准接口。团队不必为每个 Agent 重复编写内部 API 连接逻辑，而是可以把稳定、受控的业务能力封装成 MCP 工具，再交给不同的 Agent 客户端或编排平台调用。
一个实用的分层方式是：
Agent / 无代码工作流 / IDE 助手
│
▼
企业自定义 MCP Server
│
鉴权、审计、参数校验
│
▼
工单系统 / 服务目录 / 数据平台 / 内部 API
这里最重要的并不是协议本身，而是能力边界。与其开放一个可以执行任意 SQL 或任意 HTTP 请求的通用工具，不如提供 search_runbooks、get_deployment_status、create_draft_ticket 这类窄接口。接口越具体，权限审查、日志记录和后续维护越容易。
一个可以改造的只读 MCP Server
下面是一个最小 Python 示例。它从本地 JSON 文件读取已批准的运行手册，并向 Agent 暴露只读搜索工具。示例假设使用 Python 3.10 以上版本；接入真实系统时，应把本地文件替换成带身份认证的内部 API。
先创建 catalog.json：
[
{
"service": "checkout-api",
"title": "Checkout latency investigation",
"url": "https://internal.example/runbooks/checkout-latency",
"owner": "payments-platform"
},
{
"service": "identity-api",
"title": "Login error-rate response",
"url": "https://internal.example/runbooks/login-errors",
"owner": "identity-team"
}
]
再创建 server.py：
import json
from pathlib import Path
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("approved-runbook-catalog")
CATALOG_FILE = Path(__file__).with_name("catalog.json")
def load_catalog() -> list[dict]:
return json.loads(CATALOG_FILE.read_text(encoding="utf-8"))
@mcp.tool()
def search_runbooks(service: str, limit: int = 5) -> list[dict]:
"""Search approved runbooks by service name. This tool is read-only."""
query = service.strip().lower()
if not query:
return []
safe_limit = max(1, min(limit, 10))
matches = [
item
for item in load_catalog()
if query in item["service"].lower()
]
return matches[:safe_limit]
if __name__ == "__main__":
mcp.run(transport="stdio")
安装依赖并用 MCP Inspector 启动测试：
python -m venv .venv
source .venv/bin/activate
pip install mcp
npx @modelcontextprotocol/inspector python server.py
Windows PowerShell 中激活环境的命令可改为：
.venv\Scripts\Activate.ps1
这个示例刻意保持只读。改造为企业服务时，至少还应增加：
- 基于调用者身份的权限检查，而不是只信任 Agent；
- 对参数、结果条数和响应字段做白名单限制；
- 记录调用人、工具名、参数摘要、结果状态和时间；
- 对敏感字段执行脱敏；
- 为写操作增加审批、幂等键和明确的回滚路径。
尤其不要把 API 密钥写进工具描述、提示词或源代码。凭据应由运行环境的 Secret Manager 注入，并由服务端完成授权判断。
无代码和代码平台不必二选一
面向 200 人的推广计划不可能要求所有人先学会 Python。更现实的办法是建立两条构建路径，并让它们共享同一套受治理的工具。
无代码路径：快速验证业务流程
产品、运营、支持或法务人员可以在可视化平台中连接已批准的 MCP 工具，定义输入、提示词和输出格式。例如，一个“发布风险摘要”工作流可以这样实践：
# 概念性工作流，字段需按实际无代码平台调整
name: release-risk-summary
input:
- service_name
steps:
- id: find_runbooks
tool: search_runbooks
arguments:
service: "{{ service_name }}"
limit: 3
- id: summarize
prompt: |
根据已批准的运行手册生成发布前检查清单。
不要补充工具结果中不存在的内部事实。
如果没有匹配结果，明确输出“需要人工确认”。
context: "{{ steps.find_runbooks.output }}"
output: "{{ steps.summarize.output }}"
这种路径适合快速验证“流程是否值得自动化”。它的边界也很明确：复杂权限、批量操作、高风险写入和严格延迟要求，通常应该转移到代码实现。
代码路径：承载稳定且高风险的能力
工程团队负责把验证成功的流程产品化，包括测试、版本管理、可观测性、限流、错误处理和回滚。无代码原型不是最终系统，却可以成为清晰的需求说明，减少业务人员与开发人员之间的翻译损耗。
更关键的是，两条路径不应各自建立数据连接。它们应调用相同的 MCP 工具或受控服务，否则组织很快会出现重复凭据、权限漂移和无法追踪的数据出口。
不要把每个问题都变成 RAG 项目
内部 Agent 项目很容易从一个简单需求膨胀成文档切分、向量数据库、Embedding 更新、召回评估和权限同步工程。分享中提到绕开复杂 RAG，背后的工程判断很实用：如果信息已经存在于结构化 API、数据库查询或服务目录中，优先调用确定性的工具。
可以用下面的顺序判断：
- 已有 API 能直接回答吗？ 能，就封装成工具。
- 数据是结构化的吗？ 是，就优先使用带参数和权限控制的查询接口。
- 只需要少量固定文档吗？ 可以先使用人工维护的批准目录或显式上下文。
- 确实需要跨大量非结构化文档检索吗？ 再引入 RAG，并同时设计权限过滤、更新机制和评估集。
这并不是否定 RAG，而是避免在价值尚未验证时承担额外基础设施。对于两周推广计划，稳定的工具调用通常比一套仓促上线的检索系统更容易解释和治理。
安全与法务要参与设计，而不是只做上线审批
Agent 会放大现有系统的访问能力，因此安全和法务团队不能只在发布前检查一次。更高效的做法是提前共同定义“铺好的道路”：
- 允许连接哪些数据源；
- 哪些字段属于个人信息、客户数据或商业敏感信息；
- 哪些工具只能读，哪些操作必须人工批准；
- 调用日志保存多久，由谁查看；
- 模型供应商是否会保留数据；
- Agent 生成内容是否需要声明或人工复核；
- 出现误操作后如何停用工具并追踪影响范围。
可以为工具设定简单的风险等级：
| 等级 | 示例 | 建议控制 |
|---|---|---|
| 低 | 查询公开服务目录 | 身份认证、基础审计 |
| 中 | 查询内部指标或工单 | 行级权限、脱敏、限流 |
| 高 | 修改配置、发送外部消息 | 人工确认、审批、幂等与回滚 |
| 禁止 | 任意 SQL、任意 Shell、绕过权限读取 | 不向普通 Agent 开放 |
这种分类让安全审查从“逐个项目重新讨论”变成“按既定规则快速判断”，更适合大规模内部推广。
两周推广可以如何组织
如果要借鉴这种模式，可以把两周设计成一个有交付物的构建周期，而不是连续讲座：
- 准备阶段：发布工具目录、示例 Agent、安全规则和支持渠道；
- 第 1—2 天：用真实内部场景演示 MCP、提示词和工作流；
- 第 3—5 天：参与者选择一个重复性任务，完成只读原型；
- 第 6—8 天：由工程、安全和法务集中答疑并快速审查；
- 第 9—10 天：演示、复用优秀模板，并决定哪些原型进入产品化。
衡量结果时，不要只统计创建了多少 Agent。更有意义的指标包括：活跃使用人数、重复使用率、节省的人工步骤、失败率、人工接管率，以及多少 Agent 使用了经过批准的工具。
采用前的检查清单
要让员工真正从消费者转向构建者，组织需要同时降低创建成本和限制失控空间。启动之前可以确认：
- 是否有一个容易发现、带负责人和权限说明的 MCP 工具目录；
- 非技术人员是否能通过模板完成第一个只读 Agent；
- 工程人员是否能把高价值原型迁移到可测试、可部署的代码中；
- 是否优先复用现有 API，而不是默认建设 RAG；
- 每次工具调用是否可审计；
- 写操作是否具备确认、审批、幂等和回滚机制；
- 安全与法务是否已经定义允许范围，而不是逐个阻塞项目；
- 是否存在一键停用 Agent 或工具的应急机制。
两周内培养 200 名 Agent 创建者，核心不是让 200 人掌握同一种框架，而是提供一组共享、安全、可组合的积木。MCP 负责统一工具接口，无代码平台负责扩大参与面，代码平台负责承载复杂度，而安全与法务共同划定可持续扩展的边界。