什么样的智能体才算“真正能干活”？

现在，大多数“AI智能体平台”仍然停留在“高级玩具”层级，真正能干活、能连接业务流程的还凤毛麟角。 本文分享我对工具 → 数字员工 → 智能体平台三层架构的理解，以及我正在落地一个能生成、校验、发送考核报告的“数字员工”时的技术设计与实现过程。

一、不是所有“智能体”都能干活：工具才是关键

当前智能体平台五花八门：Agent、Bot、AI助手... 看似什么都能干，但一旦你想让它“真正做事”，比如：

• 打开一个 Excel 文件，读取数据、校验格式
• 访问公司后台系统发起一个审批流程
• 上传图片自动压缩重命名
• 登录企业邮箱发送一份日报

你会发现，大部分智能体平台根本做不了，或者只能通过提示词“委婉表达”，最后还是得人来操作。这是因为：它们缺乏“工具属性”。

工具属性指什么？

就是它具备 明确的 API 接口能力或代码执行能力，能操作真实系统、文件、网络，而不是停留在对话层面的虚拟建议。

二、什么是“数字员工”？它是工具的组合体

我们可以把一个“能干活的智能体”拆解为三层：

换句话说，数字员工是多个工具的编排逻辑，是从“技能”到“服务”的过渡体。

例如我正构建的一个考核自动化数字员工，背后其实是这样一个流程：

1. 读取 Excel 考核数据 →
2. 调用规则引擎生成评语 →
3. 写入模板 Word 文档 →
4. 自动转换为 PDF →
5. 根据员工邮箱批量发送邮件

这些每一步都是一个“工具”，只有把它们组合起来，这个 AI 才能被称为“员工”而不是“机器人”。

三、当前智能体平台的断点：工具能力太薄弱

为什么现在大多数智能体平台都做不好落地？

• 只会对话，不会动手
• 缺乏插件机制和运行沙箱
• 无法调用外部 API 或执行本地指令
• 无法绑定企业内系统（如 ERP、审批流、钉钉后台等）

所以，只能开始自己做：把“数字员工”的流程逻辑写成脚本或模块化函数，然后通过 MCP（模型连接协议）桥接大模型与工具层。

四、MCP：自己的“连接器”

设计：写一个 generate_summary(dataframe) 函数，然后用以下 MCP 格式描述：

{
  "tool": "generate_summary",
  "params": {
    "dataframe": "{{user_upload}}"
  },
  "description": "对上传的数据生成文本概括"
}

大模型收到任务指令后，不直接“胡说八道”，而是返回要调用的工具名称和参数结构，然后我们通过 MCP runtime 执行。

这种方式有什么好处？

• 可控：所有操作都在定义清晰的工具范围内
• 可维护：工具升级不会破坏流程
• 可集成：未来可以部署到飞书Bot、Slack、钉钉应用等任意平台

五、构建实例：考核自动化数字员工

这是目前在用的一个真实场景：

📌 背景需求：

企业每月需要给上百名员工生成考核报告，过程复杂：

1. 人事上传 Excel 表格，内容杂乱
2. 需要根据规则自动生成评语
3. 填写进模板 Word 文档中，转为 PDF
4. 批量发邮件到个人邮箱

🧩 技术实现架构：

• 接口层：Flask 服务 + MCP runtime
• 工具层：
  • read_excel(path)
  • validate_format(df)
  • generate_comment(name, score)
  • fill_word_template(data)
  • convert_to_pdf(path)
  • send_email_with_attachment(email, path)
• 调度逻辑：定义为 json 流程 + 大模型语言分析补充

💡 开发工具：

• Cursor：用于代码组织、函数封装、自动测试编写
• Python + pandas + openpyxl + win32com：工具函数开发
• 移动云智能体平台：部署交互入口 + 权限接入

上线后预期效果：

• 整体考核报告流程从人工3天 → 数字员工2小时完成
• 报错率从30%下降到5%
• 报表统一规范、可审计

六、方向：开发者定义工具，平台负责集成

我的观点是：不应该依赖大模型去“做所有事” ，而是：

• 程序员定义标准化工具（函数、API、容器服务）
• 平台通过 MCP 结构完成调用与调度
• 大模型参与流程选择与参数构造

最终形成这样的生态：

Tool API + MCP 标准 + 智能体平台宿主 → 面向企业落地的 AI 数字员工系统

🏁总结

大模型不是魔法，——除非你给它更多真正能执行的工具。

想让 AI 真正“干活”，程序员不能缺席。你不是在写 prompt，你是在设计一整条“人机协作流程”。