很多企业已经有文档搜索、知识库问答和 RAG 系统，但“能找到规则”不等于“能做出判断”。Meta 分享的一种智能代理设计思路，重点不是把更多文件塞进向量数据库，而是捕捉领域专家处理问题时使用的逻辑、约束、证据和升级路径，把这些经验沉淀为组织可以反复调用的“第二大脑”。
这个系统最初面向专业合规场景，但它的架构同样适合安全审查、财务审批、工程变更和采购决策。关键问题始终是：代理如何像一名有经验的专家一样工作，同时让人类能够检查它为什么这样判断。
从“找资料”转向“复现判断过程”
传统知识库通常解决的是信息定位问题：用户提出问题，系统检索相关段落，再生成一段回答。这种方式适合查询制度原文，却不一定适合需要综合判断的工作。
例如，一名合规专家可能会按下面的顺序处理请求：
- 判断请求属于哪个业务类别。
- 确认适用的政策版本和地域范围。
- 检查是否存在例外条款。
- 收集足够的事实和证据。
- 评估风险等级。
- 在低风险场景自动通过，在边界场景交给人工复核。
如果系统只保存“政策文档”，它还需要临时推断上述流程；如果系统保存了专家的决策逻辑，代理就可以围绕流程执行，并且在缺少输入时主动提出问题。
因此，“组织的第二大脑”不应只是一个更大的文档仓库，而应包含几类可执行知识：
- 判断步骤：先检查什么，后检查什么。
- 决策规则：哪些事实会改变结论。
- 证据要求：什么材料才足以支持判断。
- 例外和边界：规则在哪些情况下不适用。
- 升级机制：什么时候必须交给专家处理。
- 解释模板：如何说明结论、依据和不确定性。
一个可落地的代理分层
可以把这类系统拆成四层，而不是让一个大模型独自完成所有工作。
1. 输入与事实提取
代理先把自然语言请求整理成结构化事实，例如业务类型、地区、金额、数据类别、时间范围和已有证明材料。缺少关键事实时，应暂停判断并提出澄清问题。
2. 专家规则与工作流
规则层描述领域专家的判断路径。它可以由结构化规则、工作流节点和少量模型推理组成。适合明确表达的约束不应完全交给模型自由发挥，例如金额阈值、必备材料和禁止自动批准的情况。
3. 证据与可追溯性
每个结论都应关联输入事实、使用的规则和证据来源。这样，人工审核者看到的不只是“批准”或“拒绝”，还能够知道代理依据了什么、缺了什么，以及哪个环节触发了升级。
4. 人机协作与反馈
高风险或低置信度案例应进入人工队列。专家的修订不只是一次性改答案，还可以反馈为新的规则、例外案例或测试用例，逐步提高系统对组织实际做法的覆盖能力。
一个可以运行的最小示例
下面的 Python 示例不依赖第三方库，演示“专家逻辑优先于文档检索”的基本形态。它把合规判断写成显式规则，并在信息不足或风险过高时升级给人工。真实项目中，可以把 facts 的提取替换为 LLM 调用，把规则和政策版本放进数据库或配置中心。
将下面内容保存为 second_brain_agent.py，使用 Python 3 运行：
from dataclasses import dataclass
from typing import List, Dict, Any
@dataclass
class Decision:
status: str
reason: str
next_step: str
evidence_needed: List[str]
def review_request(facts: Dict[str, Any]) -> Decision:
"""一个假设的合规审查流程：规则优先，边界情况交给人工。"""
required = ["region", "data_type", "amount", "has_contract"]
missing = [name for name in required if name not in facts]
if missing:
return Decision(
status="needs_more_information",
reason=f"缺少关键事实：{', '.join(missing)}",
next_step="向申请人补充提问",
evidence_needed=missing,
)
if facts["data_type"] == "sensitive":
return Decision(
status="escalate",
reason="涉及敏感数据，不能自动批准",
next_step="提交给合规专家复核",
evidence_needed=["数据分类证明", "处理目的说明", "访问控制方案"],
)
if facts["amount"] > 10000 and not facts["has_contract"]:
return Decision(
status="blocked",
reason="金额超过阈值且缺少已签署合同",
next_step="补充合同后重新提交",
evidence_needed=["已签署合同"],
)
return Decision(
status="approved",
reason="事实满足自动审批规则",
next_step="记录审查结果并继续流程",
evidence_needed=[],
)
if __name__ == "__main__":
request = {
"region": "EU",
"data_type": "customer_contact",
"amount": 8000,
"has_contract": True,
}
result = review_request(request)
print({
"status": result.status,
"reason": result.reason,
"next_step": result.next_step,
"evidence_needed": result.evidence_needed,
})
这个小例子体现了几个重要边界：
- 信息不完整时不猜，而是继续提问。
- 高风险类型默认升级，而不是追求自动化率。
- 可编码的阈值直接写成规则，减少模型幻觉空间。
- 返回结果包含原因、下一步和所需证据，便于审计。
如果加入大模型，建议让模型负责事实抽取、规则匹配辅助和自然语言解释，而不是让它绕过规则直接给出最终结论。可以把代理输出设计成结构化 JSON，例如包含 facts、matched_rules、missing_evidence、decision 和 escalation_reason 字段，再由确定性代码执行最终的批准或拦截。
迁移到安全、财务和工程场景
这套方法的价值不在于“合规”这个具体领域，而在于它把专家工作拆成可观察的决策链。
- 安全：根据资产等级、暴露面、漏洞利用可能性和补偿控制决定是否升级。
- 财务：根据金额、供应商风险、预算归属和审批层级生成付款路径。
- 工程：根据变更范围、回滚方案、测试覆盖率和服务等级判断发布风险。
- 采购：根据合同条款、供应商类别、数据处理范围和金额阈值选择审批流程。
迁移时不要直接复制原领域的规则。更稳妥的做法是先观察专家处理一批真实案例，记录他们提出的问题、查看的证据、使用的例外和最终交接点，再把这些观察结果整理成规则与工作流。
落地时最容易忽略的风险
把专家经验误写成一句提示词
“像资深合规专家一样判断”无法替代可检查的规则。它可以作为行为风格提示，但不能承担阈值、权限和升级条件。关键决策应尽量结构化。
只评估答案准确率
代理即使给出了正确结论，也可能没有足够证据，或者走错了流程。评估指标应同时覆盖事实抽取准确率、规则命中率、证据完整性、人工升级召回率和审计可解释性。
让自动化覆盖率成为唯一目标
在合规、安全和财务场景，拒绝一次高风险自动批准通常比少处理几个低风险请求更重要。系统需要明确的“拒答”和“转人工”能力。
忽略规则版本
政策会变化，代理必须记录使用的规则版本、数据时间点和证据快照。否则，几个月后很难解释某次判断为什么成立。
一份实用的建设清单
可以按下面的顺序启动一个小范围试点：
- 选择一个决策边界清晰、案例量足够的领域。
- 收集专家处理过的真实案例，并标注事实、证据、规则和最终结论。
- 把高频判断拆成结构化字段和显式规则。
- 为不完整信息、例外情况和高风险情况设计升级路径。
- 让代理输出可审计的决策记录，而不只是自然语言答案。
- 用历史案例做离线回放，再逐步接入人工审核流程。
- 将专家修订沉淀为新规则、测试样例和版本化知识。
Meta 所描述的方向提醒我们：企业级智能代理的核心竞争力，不只是连接更多数据，而是把组织成员脑中的判断过程变成可复用、可追踪、可迭代的系统能力。真正成熟的“第二大脑”不会假装自己永远正确；它知道依据是什么、哪里缺证据，以及什么时候应该把问题交还给人。