Tool Plane 与 MCP

Tool Plane 是企业 Agent Harness 的核心资产。

更完整的 Connector / MCP 设计见 Connector 与 MCP 工具层。

核心判断

企业智能体的可靠性，不主要来自“模型知道什么”，而是来自它能否安全、准确地调用企业系统。

因此，应该把 GitHub、财务系统、CRM、项目管理系统、文档系统、BI、HR、行政、研发等能力封装成结构化工具。

企业微信和飞书适合作为统一交互入口、通知入口和身份入口，但不应被视为组织信息的完整来源。Tool Plane 的重点是跨部门业务系统的信息源接入与安全调用。

推荐形态

优先使用 MCP server 或统一 tool gateway。

示例：

```text hr_mcp - search_employee - get_leave_balance - create_onboarding_task - query_policy - draft_offer_letter

finance_mcp - read_invoice - check_reimbursement_policy - submit_expense_claim - query_budget - generate_monthly_report

rd_mcp - query_repo - create_branch - run_ci - open_pr - inspect_sentry - update_jira_ticket

crm_mcp - search_accounts - get_opportunity - list_customer_interactions - create_followup_draft

bi_mcp - query_dashboard - get_metric_definition - run_authorized_query ```

工具设计规范

每个工具都应该定义：

• 输入 schema。
• 输出 schema。
• 权限要求。
• 是否只读。
• 是否需要人工审批。
• 错误码。
• 审计字段。
• 示例调用。
• 返回证据字段。
• 字段级脱敏规则。

工具分级

等级	类型	示例	策略
L0	只读查询	查制度、查员工公开信息	默认允许，记录日志
L1	低风险写入	创建草稿、生成清单	可自动执行，允许撤销
L2	中风险动作	创建工单、修改任务状态	需要规则校验
L3	高风险动作	提交报销、发 offer、删除数据	必须人工确认

不建议的做法

• 直接让 agent 调用裸数据库。
• 把账号密码给 agent。
• 用自然语言描述复杂系统操作而不是工具 schema。
• 让不同 runtime 各自实现一套工具。

第一批工具建议

为了快速验证，可以先做：

• policy_search：检索公司制度。
• employee_lookup：查询员工基础信息。
• ticket_create：创建内部工单。
• repo_search：检索代码库。
• ci_run：运行测试或 CI。
• crm_opportunity_lookup：查询商机状态。
• bi_metric_query：查询授权指标。
• audit_log_write：记录关键操作。

支撑网页端的工具

网页端任务工作台还需要一组“产品体验工具”，它们不一定直接对应某个业务系统，但会决定普通员工是否真的能用起来：

• workspace_file_upload：上传并登记任务文件。
• workspace_file_reference：把文件授权给某个任务或 agent。
• artifact_preview：预览 agent 生成的文档、表格、报告或代码 diff。
• approval_request_create：创建人工确认请求。
• wecom_message_send：向企业微信发送通知。
• task_status_update：更新任务状态。
• task_handoff：把任务转交给其他员工或 agent。

这些工具让前端 UI、workflow 和 agent runtime 之间形成稳定契约。

支撑 Agent Bus 的工具

Agent-to-Agent 网络需要最小通信能力：

• agent_event_publish
• agent_command_request
• agent_query
• agent_artifact_publish
• agent_trace_read

第一阶段可以不做成独立基础设施，但接口设计要提前稳定下来。