Meta 讨论了一种比“文档检索机器人”更进一步的智能体：它不只是找到相关资料，而是尝试捕捉领域专家如何分析问题、应用规则、处理例外并给出结论。这个系统被称为组织的“第二大脑”，最初面向专业合规场景，但同样可以启发安全、金融、工程和采购等需要稳定决策逻辑的团队。
从“找答案”转向“复现判断过程”
传统知识库问答通常围绕两个动作展开：把资料切成片段，再根据用户问题检索相关内容。这样的系统适合回答“某条政策写了什么”，却不一定能回答“这件事应该如何判断，以及为什么”。
组织的第二大脑关注的是另一层能力：
- 识别问题类型：当前请求属于哪一类业务或风险场景？
- 调用判断规则：哪些政策、控制项或内部约定适用？
- 检查必要条件：证据是否完整，是否存在冲突或缺失？
- 处理例外情况：普通流程不适用时，应该升级给谁或补充什么信息？
- 解释决策依据：结论来自哪些规则、事实和假设？
因此，核心资产不再只是文档集合，而是专家在实际工作中反复使用的判断结构。文档仍然重要，但它更像证据和规则的来源，而不是最终产品。
一个可落地的智能体分层
可以把这类系统拆成五个相互配合的部分。下面的分层是面向实践的抽象，不代表某个特定实现的完整内部细节。
1. 事实采集层
接收用户请求、业务对象、相关文档和结构化字段。例如在合规场景中，可能包括交易类型、地区、客户属性、审批记录和合同条款。
2. 专家逻辑层
把专家经验表达成可检查的步骤，而不是一句“让模型自行判断”。规则可以包括决策树、检查清单、风险阈值、升级条件和必需证据。
3. 工具与检索层
智能体按需查询政策库、数据库、计算服务或审批系统。检索结果应作为带来源的证据输入，而不是未经验证的结论。
4. 评估与升级层
系统需要知道什么时候不能继续自动化。例如信息缺失、规则冲突、风险超过阈值，或者模型无法解释结论时，应暂停并请求人工处理。
5. 审计与反馈层
保存输入、使用的规则、引用的证据、输出结论和人工修改。这样团队才能发现规则过时、专家意见不一致或自动化误判等问题，并持续改进系统。
用一个结构化提示词约束判断流程
不要只写“请回答这个问题”。更实用的做法是要求智能体输出固定结构，并明确禁止它在证据不足时猜测。下面是一个可以直接改造的 Python 示例。它使用标准库发送 HTTP 请求，假设你的模型服务提供兼容 JSON 的聊天接口；将 LLM_ENDPOINT 和 LLM_API_KEY 替换为实际服务即可。
import json
import os
import urllib.request
endpoint = os.environ.get("LLM_ENDPOINT", "https://example.invalid/v1/chat/completions")
api_key = os.environ.get("LLM_API_KEY", "replace-me")
case = {
"request": "供应商希望访问生产环境日志，用于排查客户问题。",
"facts": {
"data_type": "production logs",
"vendor": "external vendor",
"access_duration": "temporary",
"approval": "not provided"
},
"evidence": [
{
"id": "policy-access-01",
"text": "外部人员访问生产数据前，必须完成数据范围确认和负责人审批。"
}
]
}
system_prompt = """
你是组织内部的合规决策助手。你的任务不是凭常识猜测，而是复现给定的判断流程。
请严格遵守：
1. 只使用输入事实和证据；缺少关键信息时列出缺口。
2. 区分规则原文、事实、推断和建议。
3. 发现冲突、高风险或无法确认时，输出 escalate，而不是强行批准。
4. 返回 JSON，不要添加 Markdown。
JSON 字段必须为：decision、reasoning_steps、evidence_used、missing_information、next_action。
"""
payload = {
"model": os.environ.get("LLM_MODEL", "your-model"),
"temperature": 0,
"messages": [
{"role": "system", "content": system_prompt},
{"role": "user", "content": json.dumps(case, ensure_ascii=False)}
]
}
request = urllib.request.Request(
endpoint,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
},
method="POST"
)
with urllib.request.urlopen(request, timeout=30) as response:
result = json.loads(response.read().decode("utf-8"))
print(json.dumps(result, ensure_ascii=False, indent=2))
这个例子中的关键并不是某个模型名称，而是把专家工作方式显式化：先确认事实，再匹配规则，随后检查缺口，最后决定批准、拒绝还是升级。生产系统还应对模型返回的 JSON 做模式校验，并在写入业务系统前执行权限检查。
也可以先用一段更短的提示词验证流程设计：
请按照以下顺序处理请求：
1. 提取已知事实，并标记未经证实的陈述；
2. 列出适用规则及其证据编号；
3. 检查必需条件和例外条件；
4. 如果任何高风险条件无法确认，返回 ESCALATE；
5. 输出结论、逐步理由、证据、缺失信息和下一步动作。
真正的难点在“专家知识工程”
模型本身并不会自动知道组织中的隐性规则。团队需要把专家访谈、历史案例和人工审查结果整理成机器可执行的决策资产。一个有效的起点是收集三类案例：
- 标准案例：大多数专家会快速做出相同判断的请求。
- 边界案例：规则看似适用，但存在模糊条件或例外。
- 失败案例：过去发生过误判、漏审或升级不及时的请求。
对每个案例，记录输入事实、专家使用的证据、判断步骤、最终结论以及为什么没有采用其他选项。这样的案例库比单纯增加文档数量更有助于评估智能体是否真的学会了组织的决策方式。
还要把“什么时候停止自动处理”定义清楚。自动化边界可以用简单的策略表示：
- 证据完整且规则明确：给出建议或执行下一步动作；
- 证据缺失但可以补齐：请求具体字段或材料；
- 规则冲突、风险过高或超出授权范围：升级人工；
- 输出无法追溯到证据：拒绝写入最终业务结论。
适用范围与风险边界
这种架构适合规则密集、决策重复、专家稀缺且需要审计的工作，例如合规审查、云安全配置、财务控制、工程变更和采购审批。它不意味着所有专家工作都应被自动化，也不意味着模型可以取代最终责任人。
需要重点防范几类风险：
- 规则过时：政策更新后，旧提示词或旧索引仍可能产生错误结论；
- 证据幻觉：模型引用不存在的条款，或把推断说成事实；
- 权限越界：智能体不仅给建议，还未经授权执行高影响操作；
- 反馈污染：人工修正没有经过审核就被当成新规则；
- 责任模糊：团队无法说明谁批准了结论、依据是什么。
因此，部署前应准备版本化规则、证据引用、结构化输出校验、人工升级通道和可回放审计日志。先让智能体生成带依据的建议，再逐步开放低风险动作，通常比一开始就授予完整执行权限更稳妥。
一份可以带回团队的检查清单
- 我们要复制的是哪些专家判断，而不只是哪些文档？
- 每个结论是否都能追溯到事实、规则和证据？
- 缺少信息、规则冲突和高风险时，系统是否会主动升级？
- 输出是否有固定结构，能被程序校验和审计？
- 历史标准、边界和失败案例是否都纳入评估集？
- 规则、提示词、工具权限和模型版本是否可以独立回滚？
- 自动化动作是否与建议动作分离，并受到最小权限约束？
Meta 所描述的“组织第二大脑”最有价值的启发，是把智能体建设从“接入一个模型”转成“编码一套可审计的组织判断流程”。对于任何依赖少数专家经验的团队，这种方法都值得从一个窄领域、低风险、可回放的流程开始验证，再逐步扩展到更复杂的业务决策。