智能体元观察者技能：提升AI自主决策的监控与反思能力

1. 项目概述一个面向智能体的“元观察者”技能最近在折腾智能体Agent开发特别是那些需要长期运行、具备一定自主决策能力的应用时发现一个普遍痛点智能体在执行任务时往往“埋头苦干”缺乏对自身状态和外部环境的全局感知与反思能力。这就好比一个程序员在调试代码时只盯着当前报错的那一行却忘了查看控制台日志、内存使用情况或者整个调用栈。为了解决这个问题我设计并开源了一个名为meta-watcher-skill的技能模块。简单来说它是一个可以嵌入到各类智能体框架中的“元认知”插件让智能体具备自我观察、状态监控和策略动态调整的能力。这个技能的核心价值在于它为智能体增加了一个“上帝视角”。传统的智能体流程通常是“感知 - 规划 - 执行 - 输出”执行完就结束了。而集成了meta-watcher-skill后流程变成了“感知 - 规划 - 执行 -元观察- 反思与调整 - 输出”。这个“元观察”环节就是技能发挥作用的地方。它不直接参与任务解决而是像一个随身的教练或监控系统持续收集智能体内部的“思维”痕迹如链式思考、工具调用记录、资源消耗如Token使用、API调用次数以及任务执行的中间状态并基于一套可配置的规则在关键时刻发出提醒、建议甚至触发预设的纠正策略。它适合谁呢如果你正在基于 LangChain、AutoGen、CrewAI 或是自定义的 LLM 应用框架构建复杂的、多步骤的智能体尤其是在客服自动化、数据分析流水线、自动化研发等需要高可靠性和可解释性的场景那么这个技能能显著提升你智能体的“韧性”和“透明度”。对于初学者它提供了一个理解智能体内部运作机制的绝佳窗口对于资深开发者它是一个可高度定制化的运维与调优工具箱。2. 核心设计思路为何需要“观察者”而非“执行者”在深入代码之前我们先聊聊为什么是“Watcher”观察者而不是另一个“Worker”工作者。这涉及到智能体设计的一个根本理念关注点分离。一个功能健全的智能体系统其复杂性会随着任务难度的提升而指数级增长。如果把状态监控、异常处理、策略调整这些“运维”逻辑和核心的任务解决逻辑混杂在一起代码很快就会变得难以维护和调试。meta-watcher-skill采用了经典的观察者模式Observer Pattern思想。它将智能体主体视为被观察的对象Subject而Watcher则是订阅其状态变化的观察者。这种设计带来了几个关键优势首先是解耦。智能体核心逻辑只需要专注于完成任务它无需知道谁在观察它只需在关键节点如开始思考、调用工具、产生结果、遇到错误发出事件Event即可。Watcher独立运行监听这些事件并根据自身的规则集做出反应。这意味着你可以随时增删或替换Watcher而无需修改智能体主体的任何一行代码。其次是可扩展性。你可以为不同的监控目的创建多个专门的Watcher。例如一个TokenWatcher专门监控 API 消耗在接近限额时发出警告一个LogicLoopWatcher专门检测智能体是否陷入循环推理一个SafetyWatcher检查输出内容是否符合安全规范。这些Watcher可以并行工作互不干扰。最后是决策支持而非决策替代。这是“技能”的定位。Watcher不直接接管智能体的控制权除非你配置了极端情况的强制干预规则。它更多的是提供“建议”比如“当前推理链已超过5步建议总结当前进展并重新评估目标”或者“本次工具调用耗时过长可能失败建议准备备用方案”。智能体主体可以选择采纳这些建议也可以忽略同时会被记录这保留了智能体的自主性同时也为事后分析提供了宝贵的数据。基于这个思路meta-watcher-skill被设计成一个轻量级、可插拔的 Python 包。它的核心抽象主要包括MetaWatcher核心观察者类、WatchRule规则定义、WatchEvent事件类型以及WatchReport观察报告。接下来我们拆解它的核心细节。3. 核心模块深度解析与配置要点3.1 事件系统智能体的“生命体征”监控点Watcher要观察首先得知道智能体在干什么。我们通过一个轻量级的事件系统来实现。智能体在运行过程中需要在关键节点触发相应的事件。meta-watcher-skill预定义了一系列核心事件on_agent_start/on_agent_end: 智能体任务开始和结束。这是记录任务总时长和初始化/清理资源的锚点。on_think_start/on_think_end: LLM 开始思考生成推理链和结束。这是监控 Token 消耗和思维质量的核心环节。on_think_end事件会携带模型返回的完整思考内容Chain-of-Thought。on_tool_call/on_tool_result: 调用外部工具如搜索 API、代码执行器、数据库查询和收到工具返回结果。这是监控工具可靠性、执行时长和异常的关键。on_state_update: 智能体内部状态发生变更。例如任务目标更新、上下文记忆新增、子任务完成状态标记等。on_error: 执行过程中发生任何异常。在实现上你需要在你智能体的相应位置植入事件触发代码。这通常可以通过装饰器、中间件Middleware或在基础类中重写方法来实现侵入性很低。例如在 LangChain 的 AgentExecutor 中你可以通过callbacks参数注入我们提供的事件回调处理器。注意事件携带的数据Payload要精心设计。on_think_end事件必须包含完整的 LLM 响应文本以便后续分析。on_tool_call事件应包含工具名称、输入参数on_tool_result应包含执行结果、耗时和可能的错误信息。数据越丰富Watcher的分析能力就越强。3.2 规则引擎定义“何时”以及“做什么”有了事件流Watcher需要判断在什么情况下做出反应。这就是WatchRule的作用。每条规则包含三个部分condition触发条件、action执行动作和priority优先级。触发条件Condition是一个可调用对象函数或 Lambda它接收当前事件上下文包含事件类型、数据、智能体当前全局状态等作为参数返回布尔值。条件可以非常灵活阈值型lambda ctx: ctx.token_usage 1000Token使用超1000模式匹配型lambda ctx: “循环” in ctx.last_thought最近一次思考中出现“循环”关键词状态复合型lambda ctx: ctx.tool_failures_last_5min 3 and ctx.agent_mode “critical”5分钟内工具失败超过3次且处于关键模式执行动作Action定义了触发条件后要做什么。动作也可以是函数它能够记录日志将异常情况记录到文件或监控系统。发出警告向智能体的消息队列或控制台发送一条警告信息供智能体在下一步规划时参考。触发修复执行一个预定义的修复函数比如重置某个工具的状态、切换备用的 API 密钥、甚至修改智能体的下一步目标。升级处理如果连续触发可以执行更严厉的动作如暂停任务并通知人类。优先级Priority用于解决多条规则同时被触发时的冲突。高优先级的规则先执行并且可以设置是否阻断低优先级规则的执行。一个典型的规则配置示例YAML格式在实际中通常以Python字典或类配置rules: - name: “high_token_usage_alert” event: “on_think_end” condition: “ctx.cumulative_tokens ctx.token_budget * 0.8” action: “alert” params: message: “警告累计Token使用量已超过预算的80%当前任务{{ctx.current_task}}” priority: 10 - name: “tool_timeout_fallback” event: “on_tool_result” condition: “ctx.tool_execution_time 30.0 and ctx.tool_success False” action: “execute” params: function: “switch_to_backup_tool” args: [“{{ctx.tool_name}}”] priority: 50在实际编码中我们会用 Python 类来更结构化地定义这些规则。3.3 报告与反馈闭环让观察产生价值Watcher观察到的信息不能只进不出。WatchReport模块负责生成结构化的观察报告。报告分为两种实时报告当规则被触发并执行动作时会产生一条实时日志包含时间戳、规则名、事件、触发的动作和上下文快照。这对于调试和实时告警至关重要。周期/任务总结报告在智能体任务结束时Watcher会生成一份汇总报告包括总耗时、Token 使用统计、工具调用成功率、触发的所有规则列表、以及基于事件流分析出的潜在问题如“在步骤X和Y之间出现逻辑循环倾向”。更重要的是反馈闭环。Watcher生成的警告和建议需要有一个渠道送达智能体的决策循环。最优雅的方式是通过一个共享的“建议收件箱”Advice Inbox。智能体在每次进行规划Planning前会先检查这个收件箱将未读的建议作为额外上下文纳入考量。例如【Watcher建议 12:05:03】检测到你在过去3分钟内重复查询了类似天气信息3次建议检查用户意图是否已变更或合并查询条件。智能体读到这条建议后可以在后续回复中增加一句“为了避免重复我将之前几次查询的信息整合如下...”从而显著提升交互的智能感和效率。4. 集成与实操以LangChain智能体为例理论说了这么多我们来点实际的。假设我们有一个基于 LangChain 构建的、用于分析金融新闻的智能体。现在我们要给它装上meta-watcher-skill这个“行车记录仪”和“教练系统”。4.1 环境准备与安装首先安装技能包。由于是开源项目你可以直接从 GitHub 安装开发版或者等待 PyPI 发布。pip install githttps://github.com/smouj/meta-watcher-skill.git # 或者 pip install meta-watcher-skill (未来)项目依赖通常包括pydantic用于数据验证、python-dotenv管理配置等安装时会自动处理。4.2 构建你的定制化Watcher我们不直接使用默认的Watcher而是继承它来创建符合我们金融分析场景的专属观察者。from meta_watcher_skill import MetaWatcher, WatchRule, WatchEvent from typing import Dict, Any import tiktoken # 用于精确计算Token class FinancialAgentWatcher(MetaWatcher): def __init__(self, token_budget: int 4000): super().__init__(watcher_name“financial_agent_monitor”) self.token_budget token_budget self.encoder tiktoken.encoding_for_model(“gpt-4”) # 假设使用GPT-4 self._register_custom_rules() def _register_custom_rules(self): 注册金融分析场景特有的规则 # 规则1: Token消耗预警 def high_token_condition(ctx: Dict[str, Any]) - bool: cumulative_tokens ctx.get(“cumulative_tokens”, 0) return cumulative_tokens self.token_budget * 0.75 def high_token_action(ctx: Dict[str, Any]): msg f“[Token预警] 当前累计消耗 {ctx[‘cumulative_tokens’]} tokens已超过预算({self.token_budget})的75%。建议简化后续分析或总结当前发现。” self.add_advice_to_inbox(msg, priority“high”) # 同时记录到报告 self.record_alert(“high_token_usage”, ctx) rule1 WatchRule( name“token_budget_alert”, event_typeWatchEvent.ON_THINK_END, conditionhigh_token_condition, actionhigh_token_action, priority20 ) # 规则2: 检测重复性新闻查询模拟工具调用模式 def repetitive_search_condition(ctx: Dict[str, Any]) - bool: if ctx[‘event_type’] ! WatchEvent.ON_TOOL_CALL: return False tool_name ctx.get(‘tool_name’, ‘’) # 假设我们有一个工具叫 ‘news_search’ if tool_name ‘news_search’: search_keywords ctx.get(‘input_args’, {}).get(‘query’, ‘’) # 简单逻辑检查最近3次搜索是否包含相同关键词实际应更复杂 recent_searches self.get_recent_tool_calls(‘news_search’, limit3) if any(search_keywords in s[‘query’] for s in recent_searches): return True return False def repetitive_search_action(ctx: Dict[str, Any]): advice “检测到对相似关键词的重复新闻搜索。建议1. 扩大搜索时间范围2. 使用更具体的关键词组合3. 或直接基于已有信息进行归纳。” self.add_advice_to_inbox(advice) rule2 WatchRule( name“repetitive_news_search”, event_typeWatchEvent.ON_TOOL_CALL, conditionrepetitive_search_condition, actionrepetitive_search_action, priority15 ) self.add_rule(rule1) self.add_rule(rule2) def calculate_thought_tokens(self, thought_text: str) - int: 精确计算单次思考的Token数 return len(self.encoder.encode(thought_text)) def on_think_end_callback(self, event_data: Dict[str, Any]): 重写父类方法在思考结束时计算并更新累计Token thought event_data.get(‘thought’, ‘’) tokens_this_thought self.calculate_thought_tokens(thought) self.current_context[‘cumulative_tokens’] self.current_context.get(‘cumulative_tokens’, 0) tokens_this_thought # 调用父类方法处理事件触发规则检查 super().on_think_end_callback(event_data)4.3 注入到LangChain智能体LangChain 提供了强大的回调系统Callbacks这正是我们注入事件钩子的完美入口。from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.callbacks.base import BaseCallbackHandler from langchain.schema import AgentAction, AgentFinish, LLMResult from your_financial_watcher import FinancialAgentWatcher class MetaWatcherCallbackHandler(BaseCallbackHandler): 将Watcher事件桥接到LangChain回调 def __init__(self, watcher: FinancialAgentWatcher): self.watcher watcher def on_agent_action(self, action: AgentAction, **kwargs): # 智能体调用工具时 tool_event_data { “event_type”: WatchEvent.ON_TOOL_CALL, “tool_name”: action.tool, “input_args”: action.tool_input, “log”: action.log, } self.watcher.process_event(tool_event_data) def on_agent_finish(self, finish: AgentFinish, **kwargs): # 智能体结束时 finish_event_data { “event_type”: WatchEvent.ON_AGENT_END, “output”: finish.return_values, “log”: finish.log, } self.watcher.process_event(finish_event_data) # 生成最终报告 report self.watcher.generate_summary_report() print(f“\n Watcher 任务总结报告 \n{report}\n”) def on_llm_start(self, serialized: Dict[str, Any], prompts: List[str], **kwargs): # LLM开始思考即智能体规划 self.watcher.process_event({“event_type”: WatchEvent.ON_THINK_START}) def on_llm_end(self, response: LLMResult, **kwargs): # LLM思考结束 thought_text response.generations[0][0].text # 简化获取 think_end_data { “event_type”: WatchEvent.ON_THINK_END, “thought”: thought_text, “llm_response”: response.dict(), } self.watcher.process_event(think_end_data) # 检查建议收件箱并将建议作为额外上下文可选高级用法 advice self.watcher.get_latest_advice() if advice: # 你可以在这里将advice附加到下一次LLM调用的system message或上下文中 pass def on_tool_end(self, output: str, **kwargs): # 工具执行结束 tool_result_data { “event_type”: WatchEvent.ON_TOOL_RESULT, “output”: output, “success”: not isinstance(output, Exception), } self.watcher.process_event(tool_result_data) # 在你的主程序中使用 def main(): # 1. 初始化你的智能体组件LLM, tools, prompt等 llm ChatOpenAI(model“gpt-4”, temperature0) tools [news_search_tool, financial_calc_tool] # 你的自定义工具 agent create_openai_tools_agent(llm, tools, prompt) # 2. 创建Watcher和回调处理器 financial_watcher FinancialAgentWatcher(token_budget5000) watcher_callback MetaWatcherCallbackHandler(financial_watcher) # 3. 创建AgentExecutor并注入回调 agent_executor AgentExecutor( agentagent, toolstools, callbacks[watcher_callback], # 关键注入回调 verboseTrue, handle_parsing_errorsTrue, ) # 4. 启动任务前触发开始事件 financial_watcher.process_event({“event_type”: WatchEvent.ON_AGENT_START, “task”: “分析某公司Q3财报新闻”}) # 5. 运行智能体 result agent_executor.invoke({“input”: “请总结最近一周关于苹果公司的重大新闻并分析对其股价的潜在影响。”}) # 6. 回调中的on_agent_finish会自动处理结束事件和报告4.4 运行效果与报告解读运行上述智能体当它处理复杂的新闻分析和推理时Watcher会在后台默默工作。假设智能体在分析过程中多次调用news_search并且 Token 消耗较大你可能会在控制台看到类似的输出除了智能体本身的输出[Watcher - financial_agent_monitor] [规则触发: repetitive_news_search] 检测到重复搜索模式。建议已加入收件箱。 [Watcher - financial_agent_monitor] [规则触发: token_budget_alert] Token使用预警当前累计4120 tokens。任务结束后generate_summary_report()会生成一份详细的 Markdown 报告# 智能体任务观察报告 - financial_agent_monitor **任务**: 分析某公司Q3财报新闻 **开始时间**: 2023-10-27 14:30:05 **结束时间**: 2023-10-27 14:35:22 **总耗时**: 5分钟17秒 ## 资源消耗统计 - **总Token消耗**: 4350 tokens (预算: 5000) - **LLM思考调用次数**: 8次 - **工具调用总次数**: 12次 - news_search: 8次 (成功率: 100%) - financial_calc_tool: 4次 (成功率: 100%) ## 规则触发记录 1. **repetitive_news_search** (优先级: 15) - 触发时间: 14:31:45, 14:32:10 - 上下文: 检测到对“苹果营收”关键词的连续搜索。 - 动作执行: 已发送优化建议至收件箱。 2. **token_budget_alert** (优先级: 20) - 触发时间: 14:34:50 - 上下文: 累计Token达4120超预算75%。 - 动作执行: 发送高级别预警。 ## 观察结论与建议 1. **效率提示**: 新闻搜索存在一定冗余可优化搜索策略尝试一次性获取更广时间范围的数据。 2. **资源管理**: Token使用接近预算但任务已完成。对于更复杂的查询建议考虑增加预算或优化Prompt以减少冗余输出。 3. **稳定性**: 工具调用成功率高系统运行稳定。这份报告不仅用于事后复盘更重要的是其中的“建议”部分可以直接反馈给智能体优化策略或者给开发者提供明确的优化方向比如修改 Prompt 或调整工具调用逻辑。5. 高级用法与性能优化当你的智能体系统变得庞大而复杂时基础的Watcher可能也需要升级。这里分享几个进阶玩法。5.1 分布式与异步事件处理在高并发场景下单个智能体可能产生大量事件。同步处理每个事件和规则会阻塞主线程。我们可以将事件放入一个异步队列中由后台工作线程或单独的Watcher服务消费。import asyncio import queue from concurrent.futures import ThreadPoolExecutor class AsyncMetaWatcher(MetaWatcher): def __init__(self, ...): super().__init__(...) self.event_queue asyncio.Queue() self.rule_executor ThreadPoolExecutor(max_workers2) # 规则检查线程池 self._consumer_task None async def start_consuming(self): 启动事件消费循环 self._consumer_task asyncio.create_task(self._consume_events()) async def _consume_events(self): while True: event_data await self.event_queue.get() # 将规则检查放入线程池避免阻塞事件循环 await asyncio.get_event_loop().run_in_executor( self.rule_executor, self._process_event_sync, event_data ) self.event_queue.task_done() def _process_event_sync(self, event_data): 同步处理事件原process_event的逻辑 # ... 规则匹配与执行 ... def process_event(self, event_data: Dict): 重写改为异步投递事件 asyncio.create_task(self.event_queue.put(event_data))在主程序中你需要启动事件循环并运行watcher.start_consuming()。这样智能体的执行几乎不会因为Watcher的运算而延迟。5.2 规则的热重载与动态调整在长期运行的智能体服务中你可能需要在不重启服务的情况下更新监控规则。我们可以为Watcher增加一个规则管理接口例如通过一个简单的 HTTP 端点或监听配置文件变化。import json import threading import time from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class DynamicRuleWatcher(MetaWatcher): def __init__(self, rule_config_path: str): super().__init__(...) self.rule_config_path rule_config_path self._lock threading.RLock() # 规则读写锁 self._load_rules_from_file() self._start_config_watcher() def _load_rules_from_file(self): with open(self.rule_config_path, ‘r’) as f: rule_defs json.load(f) new_rules [] for rd in rule_defs[‘rules’]: # 根据定义动态创建WatchRule对象... new_rules.append(rule) with self._lock: self.rules new_rules # 原子性替换规则列表 print(f“规则已重载当前规则数: {len(new_rules)}”) def _start_config_watcher(self): event_handler FileSystemEventHandler() event_handler.on_modified lambda event: self._load_rules_from_file() if event.src_path.endswith(‘.json’) else None observer Observer() observer.schedule(event_handler, path‘.’, recursiveFalse) observer.start()这样你只需要修改本地的rules_config.json文件保存后Watcher就会自动加载新规则并立即生效。5.3 与外部监控系统集成对于企业级应用你可能需要将Watcher的告警和报告集成到现有的监控体系如 Prometheus Grafana, Datadog, Sentry 等。from prometheus_client import Counter, Histogram, push_to_gateway import sentry_sdk class ObservabilityIntegratedWatcher(MetaWatcher): def __init__(self, ...): # Prometheus指标 self.token_usage_counter Counter(‘agent_token_usage_total’, ‘Total tokens used’, [‘agent_name’]) self.tool_call_duration Histogram(‘agent_tool_call_duration_seconds’, ‘Tool call latency’, [‘tool_name’]) # Sentry for error tracking sentry_sdk.init(dsn“YOUR_SENTRY_DSN”) def on_tool_result_callback(self, event_data): super().on_tool_result_callback(event_data) # 记录工具调用耗时指标 duration event_data.get(‘duration’, 0) tool_name event_data.get(‘tool_name’, ‘unknown’) self.tool_call_duration.labels(tool_nametool_name).observe(duration) # 如果工具调用失败发送到Sentry if not event_data.get(‘success’, True): sentry_sdk.capture_message( f“Tool {tool_name} failed for agent {self.watcher_name}”, level“error”, extraevent_data ) def push_metrics(self): 定期推送指标到Prometheus PushGateway push_to_gateway(‘localhost:9091’, jobself.watcher_name, registryREGISTRY)通过这种方式Watcher不仅是一个内置的调试工具更成为了连接智能体内部世界与外部可观测性平台的关键桥梁。6. 避坑指南与常见问题排查在实际集成和使用meta-watcher-skill的过程中我踩过不少坑这里总结一下希望能帮你绕过去。6.1 事件丢失或顺序错乱问题现象Watcher生成的报告里事件时间线对不上或者某些预期的事件根本没有被记录。排查思路检查事件触发点确保你在智能体执行流的每一个关键节点都正确触发了事件。特别是错误处理分支别忘了触发on_error事件。异步环境下的时序如果你在异步框架中使用确保事件触发是顺序的或者事件数据中包含了足够精确的时间戳和序列号以便在Watcher端重新排序。可以使用asyncio.create_task但要注意任务完成的顺序。回调注册在 LangChain 等框架中确认你的CallbackHandler被正确添加到AgentExecutor的callbacks列表并且没有被其他代码覆盖。实操心得在开发初期实现一个DebugWatcher它不做任何规则判断只是把所有接收到的事件及其完整上下文、时间戳打印到日志文件。运行一个测试任务然后对比日志和智能体的实际执行流程能快速定位事件是在哪个环节丢失的。6.2 规则条件过于敏感或迟钝问题现象告警满天飞干扰正常流程或者真正有问题时没反应。解决方案量化与缓冲避免使用绝对阈值。例如不要用“工具失败次数 0”就告警而是用“最近10次调用失败率 20%”或者“5分钟内连续失败3次”。Watcher的上下文self.current_context可以用来存储这类滑动窗口统计数据。引入延迟判断对于一些瞬时波动如单次 API 延迟高可以设置一个“冷静期”。规则触发后标记状态在接下来的一段时间内即使条件再次满足也不再触发相同告警。分级预警定义不同级别的规则。例如priority10的规则只记录日志priority50的规则发送建议到收件箱priority100的规则直接中断任务并通知人工。根据智能体所处场景的 critical 程度来配置。6.3 性能开销与影响评估问题担忧加入Watcher会不会让我的智能体变慢很多性能实测与优化轻量级规则优先规则的条件判断函数应尽可能简单高效。避免在条件函数中进行复杂的数据库查询或网络请求。如果需要复杂判断考虑将结果预先计算并存入上下文。采样与聚合对于高频事件如每一次LLM的token流输出不必每个子事件都触发规则检查。可以采用采样的方式或者仅在聚合值如每10次输出计算一次平均长度发生变化时触发检查。异步化如5.1节所述将事件处理和规则检查放到独立的线程或进程中去是消除性能影响的最有效手段。主线程只负责发射事件几乎零延迟。实测数据在我的一个中型文本处理智能体上测试集成基础Watcher约10条规则后任务总耗时增加约2-5%在可接受范围内。启用异步模式后额外开销降至1%以下。6.4 与特定智能体框架的兼容性问题问题我的智能体不是用 LangChain 写的是自定义框架怎么集成答案meta-watcher-skill的核心是事件驱动的观察者模式它与框架无关。你只需要在你的智能体执行引擎中找到对应的生命周期钩子Hooks并在那里调用watcher.process_event()即可。关键是要定义好你框架的“事件类型”与WatchEvent的映射关系。项目提供了基础的事件类型你也可以轻松扩展自定义事件。最后这个技能的威力在于持续迭代。一开始可能只监控 Token 和错误随着你对智能体行为模式的理解加深可以不断增加更“智能”的规则比如检测逻辑矛盾、识别用户意图漂移、优化资源调度策略等。它让你的智能体不再是黑盒而是一个可以持续观察、分析和优化的白盒系统。