2.1 整体系统架构中的定位

先划清边界

本节在全册架构章的第一站：先不拆零件，而是把 Deep-Researcher 放在一张更大的系统版图里看它站哪。很多团队一上手就调模块，结果发现和自家既有系统打架——比如把需要联网检索的研究智能体硬塞进纯内网流水线。读这一节，你能先划清边界，避免选型时就埋雷。

用一个系统集成的视角：研究智能体通常不是孤立存在，它左边接"问题入口"（人、工单、定时任务），右边接"知识消费方"（报告库、看板、下游 agent），下边踩"真实信息环境"（搜索接口、网页、数据库）。它的定位是这条链路里的"认知中间件"——不生产原始数据，也不直接做业务决策，只负责把杂乱信息变成可信结论。

判断它在你系统里的落点，关键看两个接口契约：输入契约是"问题长什么样"，输出契约是"报告含哪些字段"。只要这两份契约定清楚，研究智能体就能像积木一样插进现有流水线。下面用代码定义一个最薄的双契约校验，集成前先过一遍：

# 集成前校验 输入/输出契约，避免和既有系统打架
def check_contract(question: dict, report: dict) -> list:
    problems = []
    # 输入必须有明确目标与范围
    if not question.get("goal"):
        problems.append("输入缺 goal 字段")
    if "scope" not in question:
        problems.append("输入缺 scope 约束")
    # 输出必须带出处与不确定声明
    if "sources" not in report:
        problems.append("输出缺 sources 字段")
    if "uncertain" not in report:
        problems.append("输出缺 uncertain 字段")
    return problems

# 运行示例
q = {"goal": "储能技术进展", "scope": "近一年 中英文"}
r = {"sources": ["a", "b"], "uncertain": True}
print(check_contract(q, r))   # 输出 []
print(check_contract({"goal": "x"}, {"sources": []}))  # 输出 ['输入缺 scope 约束', '输出缺 uncertain 字段']
​

运行输出先是空列表（契约满足），第二条指出两处缺失。集成时最常见的问题就是输出少了 sources 或 uncertain——这会让下游消费方无法审报告，研究智能体的价值（详见 1.4）直接归零。

我们主张：定位决定架构。若你把它当"内网问答"，就别指望它有真实检索能力；若当"对外研究服务"，就必须给它联网与工具权限。先定位置，再选模块，顺序不能反。这一节的"认知中间件"视角，会在 2.2 拆模块、2.4 讲数据流时反复用到。

完整案例：背景→操作→结果→解读→变式

• 背景：某公司想在研究智能体输出的报告上直接挂"自动发给客户"的下游，但没定义输出契约。
• 操作：按上面 check_contract 先审，发现报告缺 uncertain 字段，且来源未结构化。
• 结果：补上两字段并加一道"不确定占比超阈值则转人工"的闸门后，才允许接入自动发送。
• 解读：定位是"对外服务"就必须有护栏。省掉契约校验，等于让机器替你向客户拍板。
• 变式：若定位改为"内部参谋"，下游不是客户而是分析师，则 uncertain 可降级为提示而非闸门，但 sources 仍不可省。

下一节我们钻进中间件内部，看它由哪些模块组成、各自不干什么。

定位错了会发生什么：三个真实翻车形态

2.1 把研究智能体定位成"认知中间件"，但很多团队在落地时把定位搞错，导致三种翻车。其一定位成"内网问答"，却硬接了需要联网检索的任务，结果系统搜不到外网，全程编造内部知识库里没有的内容。其二定位成"对外研究服务"，却没给护栏，自动把带不确定的报告发出去，客户收到"可能错"的结论。其三定位成"决策代理"，越权替人拍板，研究智能体的价值本在扩展带宽而非替代判断。

下面演示一个"定位—权限"映射器：不同定位对应不同的能力开关，集成前先据此校验，避免越权：

# 定位决定权限：按落点开/关能力 防止越权
def capability_for(role: str) -> dict:
    base = {"can_search_web": False, "can_auto_send": False, "can_decide": False}
    if role == "内网参谋":
        return {**base, "can_search_web": False}        # 只用内库
    if role == "研究服务":
        return {**base, "can_search_web": True, "can_auto_send": True}
    if role == "认知中间件":
        return {**base, "can_search_web": True}          # 出结论 不自动发
    return base

# 运行示例
print(capability_for("认知中间件"))   # 联网但不自动发
print(capability_for("研究服务"))     # 联网且可自动发 需护栏
​

运行输出显示"认知中间件"只开联网、不开自动发送——它负责把信息变结论，发不发由下游定。一旦你把它定位成"研究服务"并开自动发送，就必须叠加 2.4 的不确定闸门，否则机器替你向客户拍板。

💡 关键直觉：定位的本质是"划清责任边界"。你说它是什么，就决定了它该有什么权限、不该有什么权限。定位越界（如参谋去自动发）不是小毛病，是责任链断裂，出问题无人可追。

⚠️ 常见坑：忽视输入契约里的 scope。2.1 的 check_contract 只查了 goal 和 scope，实际落地还要写清"时间窗"和"语言"。scope 缺失会让系统搜出五年前的旧数据当现状，报告看着完整实则过时——这属于定位清晰但契约漏写，照样翻车。

集成落地清单（默认参数参考）

把 2.1 的定位结论落成上线前清单，最稳妥。一套常用默认：联网权限默认关、仅在定位为"认知中间件/研究服务"时开；自动发送默认关、即便研究服务也先接人工闸门；scope 默认强制含"时间窗+语言"两字段，缺则 check_contract 拒收。这些默认值把 2.1 说的安全边界变成系统出厂设置，而不是靠人记得。