企业知识库最常见的尴尬，不是模型找不到答案，而是答案说完以后，工作仍然要由人完成。微信 AI 团队开源的知识管理框架 WeKnora（维娜拉）将目标推进了一步：知识不只用于检索和生成回答，还要成为可执行流程的依据，让系统能够产出可验证的结果。
这意味着知识库的角色正在变化。传统 RAG 负责回答“应该怎么做”，面向执行的知识系统则需要继续判断“是否允许做、调用什么工具、参数从哪里来，以及执行结果是否符合预期”。
从“检索到答案”跨到“执行出结果”
传统知识库应用通常停在这条链路：
用户问题 -> 检索相关文档 -> 拼接上下文 -> 大模型生成答案
它适合制度问答、产品手册查询和客服辅助，但面对“按文档替我完成操作”时还缺少关键环节。例如，模型可以从运维手册中回答服务重启步骤，却不能因此直接获得生产环境的操作权限。
面向执行的链路更接近：
用户目标
-> 检索知识与操作规范
-> 生成结构化计划
-> 权限与风险检查
-> 调用受控工具
-> 验证执行结果
-> 记录证据并返回结果
真正困难的部分并不是增加一次函数调用，而是把自然语言知识转换成受约束、可审计的动作。文档中常见的“视情况处理”“必要时回滚”对人类很自然，对执行系统却意味着条件不明确、参数不完整和结果不可验证。
因此，评估 WeKnora 这类框架时，不应只测试召回率和回答流畅度，还要观察它是否能把文档、任务、工具和执行证据连接起来。根据已公开的摘要，WeKnora 0.8.0 的定位正是让知识库从“能查到答案”走向“能动手执行”；具体接口和部署参数仍应以对应版本的项目文档为准。
一双“手”必须配上刹车和仪表盘
知识库开始调用外部系统后，风险边界会立刻扩大。一个可以查询工单的助手与一个可以关闭工单、修改配置或发送通知的助手，安全等级完全不同。
落地时至少需要四层约束：
- 结构化动作：模型只能选择预先注册的工具，并生成经过类型校验的参数，不能直接拼接任意 Shell 或 SQL。
- 最小权限：读取、写入和高风险操作使用不同凭证；一次任务只获取完成当前动作所需的权限。
- 分级审批：查询类动作可自动执行，通知或创建类动作可以确认后执行，删除、付款和生产变更应进入人工审批。
- 结果验证：工具返回成功并不等于业务目标完成，还要重新查询状态、核对字段，并保存调用参数与响应摘要。
文档本身也必须参与治理。过期 SOP、互相冲突的制度和缺失适用范围的操作说明，一旦进入自动执行链路，影响会比普通问答更严重。知识条目最好带上版本、责任人、有效期、适用环境和风险等级，并在检索后检查这些元数据。
可以这样实践：用白名单工具搭一个最小执行闭环
下面是一个可直接运行的最小 Python 示例。它不代表 WeKnora 的真实 SDK，而是演示接入这类知识框架时应保留的执行边界。示例假设知识检索层已经返回结构化操作建议，执行层只接受白名单动作，并对写操作要求人工批准。
将代码保存为 executor_demo.py，使用 Python 3.10 及以上版本运行：
from dataclasses import dataclass
from typing import Any, Callable
@dataclass(frozen=True)
class Action:
name: str
arguments: dict[str, Any]
requires_approval: bool = False
def get_service_status(service: str) -> dict[str, str]:
# 实际项目中替换为监控平台或服务治理 API。
return {"service": service, "status": "degraded"}
def create_ticket(service: str, reason: str) -> dict[str, str]:
# 实际项目中替换为工单系统 API，并使用最小权限凭证。
return {
"ticket_id": "INC-2025-001",
"service": service,
"reason": reason,
"status": "created",
}
TOOLS: dict[str, Callable[..., dict[str, str]]] = {
"get_service_status": get_service_status,
"create_ticket": create_ticket,
}
def execute(action: Action, approved: bool = False) -> dict[str, Any]:
tool = TOOLS.get(action.name)
if tool is None:
raise ValueError(f"Tool is not allowlisted: {action.name}")
if action.requires_approval and not approved:
return {
"status": "waiting_for_approval",
"action": action.name,
"arguments": action.arguments,
}
result = tool(**action.arguments)
return {
"status": "executed",
"action": action.name,
"evidence": result,
}
if __name__ == "__main__":
# 假设该计划来自“知识检索 + 模型规划”，而不是让模型直接执行代码。
plan = [
Action("get_service_status", {"service": "payment-api"}),
Action(
"create_ticket",
{
"service": "payment-api",
"reason": "Runbook says to create an incident when status is degraded",
},
requires_approval=True,
),
]
for action in plan:
first_result = execute(action)
print(first_result)
if first_result["status"] == "waiting_for_approval":
approved_result = execute(action, approved=True)
print(approved_result)
运行命令：
python3 executor_demo.py
接入真实系统时，可以把 WeKnora 或其他知识层放在计划生成之前：先检索适用的操作规范，再要求模型只输出符合 JSON Schema 的动作。执行器仍应作为独立服务存在，因为权限校验、审批和审计不能只依赖提示词。
一个可供模型输出的动作格式可以约束为：
{
"action": "create_ticket",
"arguments": {
"service": "payment-api",
"reason": "Health check failed three times"
},
"knowledge_refs": ["runbook-payment-v3"],
"requires_approval": true
}
其中 knowledge_refs 很重要：它让执行决定能够追溯到具体知识版本。审核人员不仅能看到模型想做什么，还能检查它依据了哪份文档。
上线前别只测“答得对不对”
采用 WeKnora 这类执行型知识框架时，可以从只读、可回滚、低风险的任务开始，例如查询服务状态、汇总告警、生成工单草稿或准备变更计划。直接开放生产写权限，会把文档错误、检索偏差和模型误判叠加成一次真实事故。
上线检查应覆盖以下项目：
- 每个工具都有固定参数模型、超时、重试策略和调用上限。
- 模型无法提交任意代码、Shell、SQL 或目标 URL。
- 高风险动作必须经过独立于模型的策略引擎或人工审批。
- 每次执行记录用户目标、知识引用、模型计划、工具参数和验证结果。
- 知识版本失效、检索不到依据或多个规则冲突时，系统默认停止执行。
- 评测集同时包含正常任务、越权请求、提示注入、过期文档和工具失败场景。
WeKnora 0.8.0 值得关注的核心，不只是又多了一个知识库框架，而是它把问题指向了 RAG 落地的下一阶段：答案必须连接到动作，动作必须产生证据，证据必须能够被复核。真正可用的“会动手”知识库，不是让模型拥有无限工具，而是让它在明确权限、知识版本和验证规则内完成有限但可靠的工作。