5.5 面临的挑战与解决方案

真实泥泞里的墙

本节收束实践章：部署一定会撞墙，这一节把三面最常见的墙列出来并给翻法。全册前四节讲的是"理想路径"，这里讲"真实泥泞"。我们给一个直接定义：挑战是架构在真实约束下的失效模式，解决方案不是补丁，而是把失效变成可控事件。三类典型墙——反爬挡检索、长文截断丢证据、成本失控爆预算。

墙一：反爬。网页代理（2.3）被目标站限流或验证码拦截，检索结果骤减。翻法不是硬刚反爬（合规风险高），而是多后端冗余+降级：主源失败时切备用源，仍不足则标"该方向证据不足"转人工（呼应 4.2 空白）。墙二：长文截断。模型上下文有限，长报告被切导致后半证据丢失。翻法是分层摘要（5.4）+字段化存储，先抽命题入库再综合，不依赖一次性全文。墙三：成本失控。循环没早停，步数爆表。翻法是预算硬上限（5.2 token_cap）+早停（5.4）。

# 三类故障的统一处理：检测->降级->留痕
def handle_failure(kind: str, state: dict) -> str:
    if kind == "anti_crawl":
        if state.get("backup_available"):
            return "切备用源"
        return "标证据不足转人工"
    if kind == "truncation":
        return "改用分层摘要+命题入库"
    if kind == "cost_overrun":
        if state["spent"] > state["cap"]:
            return "触发预算硬上限 终止并成稿"
    return "未知故障 告警"

# 运行示例
print(handle_failure("anti_crawl", {"backup_available": False}))   # 标证据不足转人工
print(handle_failure("cost_overrun", {"spent": 250000, "cap": 200000}))  # 触发预算硬上限
​

运行输出两行：反爬无备用时转人工、成本超帽时终止成稿。关键点——每种故障都有"兜底动作"而非卡死。这正呼应 2.3 说的"可熔断"：工具会坏，系统不能跟着坏。

我们主张：解决方案的设计目标是"失败可预期"。你无法杜绝反爬、截断、超预算，但可以让每次失败都走预定路径并留痕（2.4 的调用留痕），而非随机崩溃。可预期失败比偶发成功更有工程价值——前者能复盘、能改，后者只能祈祷。

下面演示"反爬多后端"的具体切换逻辑，看冗余怎么配：

# 反爬冗余：主源失败自动切备用 仍失败则认空白
BACKENDS = ["search_main", "search_backup", "web_agent"]

def retrieve_with_fallback(query: str, failed: set) -> str:
    for b in BACKENDS:
        if b not in failed:
            # 模拟：主源已失败 试备用
            if b == "search_main":
                failed.add(b)
                continue
            return f"命中:{b}"
    return "全失败 标空白转人工"

print(retrieve_with_fallback("量子 药物", set()))
# 命中:search_backup
​

输出 命中:search_backup——主源失败自动跳到备用，没让任务卡住。若全失败，则按 handle_failure 转人工。冗余不是浪费，是真实环境的保险。

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

• 背景：某系统主搜索源被限流，整批周报空壳，无人察觉。
• 操作：加 retrieve_with_fallback 多后端 + 全失败转人工 + 调用留痕。
• 结果：主源故障时自动切备用，偶发全失败时报告标空白并告警，空壳率归零。
• 解读：墙不可怕，怕的是墙后无路。冗余+降级把隐性故障显形可管。
• 变式：若合规要求只用指定源（不可切备用），则主源失败直接标空白转人工，不引入未授权源——合规优先于覆盖。

第五章收口：开源选型（5.1）、配置（5.2）、场景（5.3）、优化（5.4）、挑战（5.5）已把能力接回地面。三类墙之外，还有个"软墙"：组织流程。技术能翻前三堵墙，但报告出来没人审、没人用，系统仍废。我们见过团队部署完美，却因没把"不确定转人工"接进真人工作流，告警石沉大海。翻法是把人工闸门做成待办而非邮件——转人工即建任务，超时升级。技术护栏要和组织护栏咬合，否则最稳的系统也死在"没人看"。这把 5.5 从纯技术扩到人机协同，也预告第六章的伦理视角。

再说一个排障铁律：先量后修。墙出现别急着加后端、改提示，先查监控——是反爬（失败率突增）、截断（输出变短）、还是成本（步数爆）？三类症状不同，治法不同。乱改往往按下葫芦浮起瓢。我们建议每类故障配一个"指纹指标"（失败率、输出长度、步数），告警即定位，省去猜。这和第 4 章的过程导向同源：能测才能改，不能测的优化是盲调。

墙还会"变异"。今天反爬用验证码，明天换行为指纹；今天截断在长度，明天在格式。所以故障指纹（5.5 提到的失败率、输出长度、步数）要持续更新，不能定一次用一年。我们建议每季度复盘一类新墙，补进 handle_failure 与监控。研究智能体的运维是持续的，不是上线即终。这点和 3.1"真实环境会演化"同源——你训好不代表环境静止。

再补一个软指标："人工闸门积压量"。若转人工的任务越积越多，说明系统前四堵墙没挡住、把活全推给人，等于变相失败。积压量应和失败率一起监控，它暴露的是"系统退化为纯转人工"的隐蔽退化。健康的研究智能体，人工应是"例外"而非"常态"。

工具失效还有"优雅退化"一说。反爬挡了主源，系统不该只切备用，还应主动降"覆盖预期"并在报告标明"本方向仅基于备用源"。这把 5.5 的降级从"能不能跑"升到"跑得诚不诚实"——降级同时降级置信，而非照常自信。工程上，每个工具健康度应实时影响综合分里的"整合"与"诚实"维度（呼应 4.3、4.4），而不是只影响"是否报错"。工具的生老病死要进评估，而非绕开评估。这是把 2.3 的可观测真正用起来：监控数据不沉睡在仪表盘，而直接改写系统的自我评估报告。

第六章我们把时间轴拉长，看它往哪演化、又逼我们负什么责。