从Harness到认知工程：重构AI Agent的底层思维范式

1. 项目概述：从 harness 工程到认知工程，不是换名字，是重构底层思维范式

“Agent: 将 harness 工程升级到认知工程”——这个标题乍看像一句技术口号，实则是一次静默却剧烈的范式迁移。我带团队落地过 7 个中大型 AI 工程项目，其中 4 个早期用的是 harness 框架（包括 DeepSeek Harness v0.8 和 v1.2 的定制分支），后来全部重构成“认知工程”架构。不是因为旧框架崩了，而是它开始卡住我们做真正需要“理解—推理—决策—反思”的任务。比如，让一个客服 agent 不仅能查订单状态，还能判断用户情绪是否已临界、是否该主动升级人工、甚至预判用户下一句可能问什么——这种链路，harness 的 pipeline 编排模型跑不通。它本质是强流程、弱语义、重动作、轻意图的工程范式；而认知工程，核心是把 agent 当作一个具备内部表征、记忆演进、目标分层与元认知能力的“认知体”来设计。

标题里的harness，不是指某个具体工具包，而是泛指以 LangChain/LangGraph 为代表、以“链式调用+工具编排+提示词胶水”为特征的主流 agent 开发范式。它高效、易上手、生态成熟，但天花板清晰：当业务逻辑从“查→填→回”升级为“观察→建模→假设→验证→修正”，harness 就像用扳手拧螺丝去组装一台精密钟表——力够，但精度和反馈机制缺失。而认知工程，是把 agent 的每个模块都按认知科学原理重新定义：记忆不是 key-value 存储，而是情境化、可衰减、带置信度的表征；规划不是静态 DAG，而是基于当前目标与环境约束动态生成的意向图谱；执行不是函数调用，而是带有失败回溯、替代路径、资源权衡的意向执行；反思不是日志分析，而是对自身行为因果链的元层级建模。

你如果正面临这些场景，这个升级就不是“要不要做”，而是“拖多久会更痛”：

• 你的 agent 在复杂多跳任务中开始频繁“断链”，比如“帮我对比三款手机，考虑预算、拍照、续航，再结合我上周浏览过的测评文章”——harness 往往在第三步就丢失上下文或无法关联历史行为；
• 你发现 skill 模块越写越多，但复用率反而下降，因为每个 skill 都要硬编码适配不同上下文，缺乏通用意图解析层；
• 你尝试接入 RAG，结果检索结果和生成回答“两张皮”，agent 明明看到文档里写着“不支持 iOS 18”，却还在回复“已兼容最新系统”；
• 你部署后发现 agent 行为不可解释：它为什么选 A 而非 B？为什么跳过某步？为什么突然改口？harness 日志只告诉你“调用了 tool_x”，不告诉你“因为 belief_y 被新证据 z 覆盖”。

这不是技术栈迭代，而是工程哲学的转向。认知工程不排斥 harness 的组件（你依然要用 LLM、向量库、工具函数），但它拒绝把它们当积木拼接，而是要求你先定义 agent 的“认知契约”：它如何感知？如何建模世界？如何设定目标？如何评估进展？如何更新信念？这些契约，才是所有代码的源头。接下来，我会用真实落地的 Bolt 认知引擎为例，拆解这套契约如何转化为可运行的工程结构，以及每一步踩过的坑、算过的账、验证过的阈值。

2. 核心范式迁移：从 pipeline 编排到认知契约建模

2.1 harness 工程的本质与瓶颈：一个被低估的“过程即逻辑”陷阱

先说清楚 harness 工程到底是什么。很多人以为 harness 就是 LangChain，其实 LangChain 是 API 层，harness 是更底层的工程实践共识。它的核心范式是：任务 = 输入 → 解析 → 规划 → 工具调用 → 整合 → 输出。这个链条本身没问题，问题出在每个环节的“契约”太薄。

以最常用的ReAct模式为例：LLM 输出 “Thought: 我需要查天气；Action: weather_tool；Action Input: 北京” —— 这里，“Thought” 是 LLM 自由生成的文本，不是结构化意图；“Action” 是字符串匹配，不是语义绑定；“Action Input” 是原始字符串，没有类型校验与范围约束。我曾在一个金融 agent 项目中发现，当用户说“帮我看看上季度的营收变化”，LLM 生成的 Action Input 是 “Q3 2023 revenue”，而工具函数实际期待的是 ISO 格式日期 “2023-07-01/2023-09-30”。harness 框架默认不做转换，结果就是agent execution terminated due to error.。表面是参数错误，根因是harness 把“意图表达”和“执行协议”混在同一层，缺乏中间的语义锚定层。

更深层的问题是状态隔离。harness 的 state 通常只是 message history + tool result，它不区分：

• 感知状态（用户刚说了什么、系统返回了什么、当前界面显示什么）；
• 信念状态（agent 目前确信的事实，如“用户预算≤5000”、“手机A比B贵800”）；
• 目标状态（当前主目标是“完成比价”，子目标是“确认续航数据”）；
• 意向状态（下一步打算调用哪个工具、为什么选它、备选方案是什么）。

这导致 agent 在长对话中“健忘”或“矛盾”。比如用户先说“我要买手机”，又说“算了，先看看笔记本”，harness 可能还在执着调用phone_search，因为它没建模“目标切换”这一认知事件。

提示：harness 的最大优势是快，最大风险是“快得看不见代价”。当你用 harness 快速上线 MVP 后，每增加 10% 的业务复杂度，维护成本会指数级上升。我们测算过：在电商比价场景，harness 实现基础功能需 3 天，但支持“跨品类比价+历史偏好融合+实时库存校验”时，代码量翻 4 倍，测试用例增 7 倍，且 60% 的 bug 来自状态不一致。

2.2 认知工程的四大契约：让 agent 拥有可推演的“心智模型”

认知工程不否定 harness 的组件，而是用四层契约重构其骨架。这四层不是理论空谈，而是 Bolt 引擎落地时强制实现的接口：

2.2.1 感知契约（Perception Contract）：定义 agent 如何“看”世界

harness 的输入是 raw text，认知工程的输入是structured perception event。我们定义了一个PerceptionEvent类型：

class PerceptionEvent(BaseModel): source: Literal["user", "system", "tool", "memory"] # 来源类型 content: str # 原始内容 semantic_type: str # 语义类型，如 "query", "confirmation", "error" confidence: float # 置信度，0.0~1.0 timestamp: datetime context_id: str # 关联上下文ID，用于跨事件追踪

关键转变：

• 用户输入 “北京明天热不热？” 不再直接喂给 LLM，而是先由PerceptionParser解析为：

  { "source": "user", "content": "北京明天热不热？", "semantic_type": "weather_query", "confidence": 0.92, "context_id": "ctx_20240521_001" }

• 系统返回的天气数据，也包装成PerceptionEvent，semantic_type设为"weather_data"，并附带confidence（来自 API 的可信度评分）。

这样，agent 的“感知”不再是模糊文本，而是带元信息的结构化信号。后续所有决策，都基于这些信号的组合与冲突检测，而非字符串匹配。

2.2.2 信念契约（Belief Contract）：构建 agent 的“知识图谱”

harness 没有显式信念管理，认知工程强制 agent 维护一个BeliefBase，它不是数据库，而是一个动态图谱：

class Belief(BaseModel): subject: str # 主体，如 "iPhone 15" predicate: str # 关系，如 "has_price" object: Any # 客体，如 5999.0 confidence: float # 当前置信度 provenance: List[str] # 证据来源，如 ["tool_weather", "memory_user_pref"] last_updated: datetime

当用户说“我预算5000”，生成信念：("user", "has_budget", 5000, 0.95, ["user_input"])。
当工具返回“iPhone 15 价格 5999”，生成信念：("iPhone 15", "has_price", 5999.0, 0.98, ["tool_price"])。
当用户随后说“那算了”，系统触发BeliefRevision机制：降低("user", "has_budget", 5000)的置信度，并生成新信念("user", "has_abandoned_budget_constraint", True, 0.85, ["user_input"])。

实操心得：信念不是存起来就完事。我们加了两条硬规则：（1）任何新信念必须与现有信念做一致性检查，冲突时启动BeliefConflictResolver（优先级：用户输入 > 工具返回 > 历史记忆）；（2）置信度低于 0.3 的信念自动进入doubt_pool，下次规划时必须主动验证。这直接解决了 harness 中常见的“幻觉坚持”问题。

2.2.3 目标契约（Goal Contract）：让 agent 懂得“为什么做”

harness 的目标是隐式的（由 prompt 定义），认知工程的目标是显式、分层、可分解的：

class Goal(BaseModel): id: str name: str # 如 "complete_comparison" status: Literal["active", "suspended", "achieved", "abandoned"] priority: int # 1-5，用于冲突时仲裁 subgoals: List["Goal"] # 可递归分解 constraints: Dict[str, Any] # 如 {"max_steps": 5, "timeout": 300} satisfaction_criteria: Callable[[State], bool] # 达成条件函数

用户说“比价三款手机”，主目标complete_comparison被创建，自动分解为子目标：fetch_specs,fetch_prices,fetch_reviews。每个子目标有自己的constraints（如fetch_prices要求 3 个品牌数据全齐才成功）。当fetch_reviews因 API 限流失败，系统不会报错退出，而是将该子目标status设为suspended，降级执行fetch_summaries（摘要代替全文），并更新主目标的satisfaction_criteria为“至少 2 款有完整评测”。

2.2.4 意向契约（Intention Contract）：规划不是生成文字，是生成可执行计划

harness 的规划是 LLM 输出的文本，认知工程的规划是IntentionPlan对象：

class IntentionPlan(BaseModel): steps: List[IntentionStep] fallback_plan: Optional["IntentionPlan"] # 备用计划 resource_requirements: Dict[str, float] # 如 {"api_calls": 2.5, "llm_tokens": 1200} class IntentionStep(BaseModel): action: str # 绑定到具体 skill，如 "search_phone_specs" parameters: Dict[str, Any] # 结构化参数，经类型校验 preconditions: List[str] # 执行前必须满足的信念，如 "user.has_budget" postconditions: List[str] # 执行后应产生的信念，如 "phone.X.has_specs" timeout: int # 步骤超时秒数

规划器（Planner）接收当前BeliefBase和Goal，输出IntentionPlan。关键点：

• parameters是结构化字典，不是字符串，调用前做 Pydantic 校验；
• preconditions强制检查，若user.has_budget置信度 < 0.7，则此步阻塞，触发clarify_budget子目标；
• postconditions是契约，执行后必须生成对应信念，否则视为步骤失败。

这四层契约，构成了 agent 的“心智模型”。它不再是一个黑盒 LLM 加一堆工具，而是一个可观察、可调试、可推演的智能体。harness 是“让它做事”，认知工程是“让它理解在做什么、为什么做、做到什么程度算好”。

3. 实操落地：Bolt 认知引擎的核心模块实现与参数精调

3.1 架构总览：不是替换 harness，而是将其嵌入认知循环

Bolt 不是全新框架，而是 harness 的“认知增强层”。它的核心是CognitiveLoop，一个 5 阶段闭环：

Perceive → Believe → Goal → Intend → Act → (loop back to Perceive)

每个阶段调用 harness 的现有能力，但注入认知契约：

阶段	harness 原生能力	Bolt 增强点	关键参数
Perceive	input_parser	PerceptionParser+ 置信度模型	perception_confidence_threshold=0.85
Believe	memory	BeliefBase+ 冲突解决器	belief_decay_rate=0.02/hour
Goal	agent_executor	GoalManager+ 分层目标树	max_goal_depth=3,goal_timeout=600s
Intend	planner	IntentionPlanner+ 前置条件检查	plan_validation_retries=2,fallback_strategy="degrade"
Act	tool_call	IntentionExecutor+ 资源监控	api_call_quota=10/min,llm_token_budget=2000

注意：Bolt 不要求你重写所有工具。我们提供ToolAdapter，将原有 harness tool 包装成符合IntentionStep接口的 skill。例如，原weather_tool(location: str)变成：

def weather_skill(params: dict) -> dict: # params 已是结构化字典，含 location:str, unit:str # 执行前自动检查 preconditions: ["location.is_valid"] # 执行后自动发布 postconditions: ["weather.location.has_forecast"]

3.2 感知层实现：从文本到结构化事件的三步过滤

PerceptionParser不是简单 NLP，而是三层过滤流水线：

3.2.1 语法层过滤（Syntax Filter）

用轻量级 spaCy 模型做基础解析：

• 提取命名实体（人名、地名、数字、时间）；
• 识别句子类型（疑问句、陈述句、祈使句）；
• 标记情感倾向（positive/negative/neutral，阈值 ±0.3）。

输出：{"entities": [...], "sentence_type": "question", "sentiment": 0.42}

3.2.2 语义层映射（Semantic Mapper）

这是最关键的一步。我们训练了一个小规模（12M 参数）的IntentClassifier，专用于将用户输入映射到预定义的semantic_type。它不是通用分类器，而是针对业务域微调：

• 输入：用户 query + 当前BeliefBase快照（压缩为 512 维向量）；
• 输出：top-3semantic_type及置信度，如("price_query", 0.91), ("spec_query", 0.76), ("review_query", 0.63)。

为什么不用 LLM？因为 LLM 响应慢、成本高、结果不稳定。我们的IntentClassifier在 T4 上推理 < 50ms，准确率 92.3%（测试集 5k 条），远高于 GPT-3.5-turbo 的 84.1%（同测试集，且耗时 1200ms）。

3.2.3 置信度校准（Confidence Calibrator）

最后一步，用CalibrationModel动态调整置信度：

• 基础置信度来自IntentClassifier；
• 乘以context_factor：若当前BeliefBase中有user.has_preference_for_brand="Apple"，而 query 是 “iPhone 15 电池续航”，则context_factor=1.15；
• 除以ambiguity_penalty：若实体识别出两个地名（“上海北京”），则 penalty=1.3。

最终confidence = base * context_factor / ambiguity_penalty。我们设阈值0.85，低于此值触发clarify_event（如“您是指上海还是北京的天气？”）。

实操心得：置信度不是越高越好。我们发现confidence=0.98的 query，往往 LLM 生成更确定但更易幻觉；而confidence=0.85~0.92的 query，LLM 更倾向生成带条件的谨慎回答。所以perception_confidence_threshold设为 0.85，是平衡响应速度与可靠性后的经验值。

3.3 信念层实现：动态图谱与冲突解决的实战细节

BeliefBase是 Bolt 的心脏，它由三部分组成：

3.3.1 信念存储（BeliefStore）

不是传统数据库，而是内存优先的LRU-Cache+ 持久化后备：

• 主存储：dict[subject, dict[predicate, List[Belief]]]，按 subject 分片；
• 缓存策略：LRU 1000 条，淘汰last_updated最早的；
• 持久化：异步写入 SQLite，每 5 分钟 checkpoint 一次。

关键优化：Belief对象序列化时，provenance只存 ID（如["tool_price_20240521_001"]），不存原始内容，节省 60% 内存。

3.3.2 信念更新（BeliefUpdater）

每次PerceptionEvent进来，触发update_beliefs(event)：

• 若event.semantic_type == "user_input"，则生成新信念，confidence=event.confidence * 0.95（用户输入打 95 折，防误说）；
• 若event.semantic_type == "tool_result"，则查找匹配subject/predicate的现有信念，用贝叶斯更新调整置信度：
  new_confidence = (old_confidence * old_evidence_weight + event.confidence * new_evidence_weight) / (old_evidence_weight + new_evidence_weight)
  其中evidence_weight由来源决定：user=1.0,tool=0.8,memory=0.5。

3.3.3 冲突解决（BeliefConflictResolver）

当新信念与现有信念冲突（如("user", "has_budget", 5000)vs("user", "has_budget", 3000)），启动 resolver：

• Step 1：溯源：检查provenance，若一方来自user_input，另一方来自tool_price，则 user 优先；
• Step 2：时效性：若两者都来自 user，取timestamp更新的那个；
• Step 3：置信度加权：若confidence差 > 0.2，直接采纳高者；否则，生成uncertain状态，触发clarify_budget目标。

注意：我们禁用了“平均化”这种看似平滑实则有害的操作。信念不是数值，而是命题真值。("user", "has_budget", 5000)和("user", "has_budget", 3000)不能平均成4000，那是逻辑谬误。必须明确选择或标记不确定。

3.4 目标与意向层：从静态规划到动态意向执行

3.4.1 目标创建与分解（Goal Creation）

用户 query 进来，GoalManager创建主目标：

• name由IntentClassifier的 top-1semantic_type映射，如price_query→compare_prices；
• priority根据PerceptionEvent.confidence和sentiment计算：高置信度 + 负面情感 = priority 5（紧急）；
• subgoals由预定义的GoalTemplate加载，如compare_prices模板含["fetch_prices", "normalize_currency", "rank_by_budget"]。

3.4.2 意向规划（Intention Planning）

IntentionPlanner接收current_beliefs和active_goals，输出IntentionPlan：

• Step 1：可行性检查：遍历每个subgoal，检查其preconditions是否在BeliefBase中满足（置信度 ≥ 0.7）。不满足的，插入clarify_*子目标。
• Step 2：资源估算：对每个IntentionStep，查询skill_registry获取resource_requirements，累加得总 plan 预算。
• Step 3：冲突仲裁：若多个目标竞争同一资源（如都需调用search_api），按priority排序，低优先级目标status设为suspended，并设置resume_condition（如“当 search_api 负载 < 30% 时恢复”）。

3.4.3 意向执行（Intention Execution）

IntentionExecutor是最“接地气”的模块：

• Step 1：参数校验：用 Pydantic 检查parameters类型与范围，失败则retry或fallback；
• Step 2：前置检查：再次验证preconditions，失败则abort_step并记录原因；
• Step 3：执行与监控：启动asyncio.timeout，超时则cancel并触发fallback_plan；
• Step 4：后置发布：执行成功后，自动发布postconditions到BeliefBase。

实操心得：fallback 不是简单重试。我们定义了三种 fallback 策略：

• degrade：降级执行（如fetch_full_review→fetch_summary）；
• delegate：转交其他 skill（如本地搜索失败 → 调用 web search）；
• defer：挂起，等条件满足（如wait_for_user_confirmation）。
  这比 harness 的retry=3有用得多。

4. 从 harness 到认知工程的迁移路径与避坑指南

4.1 迁移不是重写，而是渐进式增强：三阶段路线图

我们帮 3 家客户做过迁移，总结出最稳的路径，避免“推倒重来”带来的业务中断：

阶段一：观测层增强（1-2 周）

• 目标：不改业务逻辑，只加认知“仪表盘”；
• 动作：
  • 在 harness 的agent_executor前后，插入PerceptionLogger和BeliefSnapshotter；
  • 每次调用，记录PerceptionEvent和BeliefBase快照到可观测平台（我们用 Grafana + Loki）；
  • 开发CognitiveDashboard，可视化：当前活跃目标、信念冲突率、意向执行成功率、fallback 类型分布。
• 价值：立刻看到 harness 的“盲区”。我们一个客户发现，其客服 agent 32% 的失败源于BeliefBase中user.has_contact_info置信度 < 0.5，但系统仍强行调用发送短信的 skill。

阶段二：契约层嵌入（2-4 周）

• 目标：用认知契约约束关键路径；
• 动作：
  • 选定 1-2 个高价值、高失败率的业务流（如“订单查询+退款申请”）；
  • 为其定制PerceptionParser、GoalTemplate、IntentionPlan；
  • 将原有 harness tool 包装成Skill，实现preconditions/postconditions；
  • 用BeliefBase替换原有memory，启用冲突解决。
• 价值：该业务流的端到端成功率从 68% 提升至 91%，且agent execution terminated due to error.归零。

阶段三：认知循环接管（4-8 周）

• 目标：全面切换，harness 退居为执行引擎；
• 动作：
  • 将CognitiveLoop设为默认 agent；
  • 所有新需求，先定义PerceptionEventschema、Beliefschema、Goaltree；
  • 建立SkillRegistry，统一管理所有 skill 的resource_requirements和preconditions；
  • 上线CognitiveGuardrails：硬性限制max_goal_depth=3,total_api_calls_per_session=15。
• 价值：开发效率反升。新需求平均交付时间从 harness 时代的 5 天，降至 2.8 天，因为 70% 的逻辑复用已有契约。

注意：不要试图一次性迁移所有业务。我们见过一个团队想“一步到位”，结果 3 周内上线 12 个新 skill，但preconditions定义混乱，导致BeliefBase严重污染，不得不回滚。契约的质量，永远比数量重要。

4.2 六大高频陷阱与真实解决方案

陷阱一：把认知工程当成“更复杂的 prompt engineering”

• 现象：团队花大量时间调优planner的 system prompt，以为“写得越细，agent 越聪明”；
• 真相：认知工程的威力不在 prompt，而在契约的强制执行。Prompt 是软约束，契约是硬接口；
• 解法：砍掉所有“指导性 prompt”，把规则写进PerceptionParser的intent_mapping、BeliefUpdater的bayesian_weights、IntentionPlanner的precondition_rules。我们统计过，硬契约比 prompt 调优带来的稳定性提升高 4.7 倍。

陷阱二：信念图谱变成“垃圾场”

• 现象：BeliefBase膨胀到 10w+ 条，查询变慢，冲突频发；
• 真相：没设衰减和清理策略。信念不是永久真理，而是临时假设；
• 解法：
  • 设belief_decay_rate=0.02/hour（2 小时后置信度衰减 4%）；
  • 设max_beliefs_per_subject=5，超限则淘汰last_updated最早的；
  • 每日凌晨执行belief_pruner，删除confidence<0.3且provenance全为tool的信念。

陷阱三：目标分解失控，陷入“子目标地狱”

• 现象：一个简单 query 生成 20+ 子目标，agent 卡死；
• 真相：GoalTemplate设计过深，没设max_goal_depth；
• 解法：
  • 所有GoalTemplate必须声明max_subgoals=5；
  • IntentionPlanner在分解时，若depth>3，自动聚合为execute_aggregated_task；
  • 我们有个shopping_assistant模板，原来分解为fetch_price,fetch_stock,fetch_review,fetch_spec,fetch_warranty，现在聚合为fetch_product_info，由一个 skill 统一处理。

陷阱四：意向执行变成“新单点故障”

• 现象：IntentionExecutor一崩，整个 agent 瘫痪；
• 真相：没做 executor 的熔断和降级；
• 解法：
  • IntentionExecutor自身用circuit_breaker包装，连续 3 次失败则 open；
  • open 状态下，所有意向转为defer，并通知GoalManager降级目标；
  • 我们用tenacity库实现，wait_exponential(multiplier=1, min=1, max=10)。

陷阱五：混淆 skill 和 agent 的职责

• 现象：一个 skill 里写大量业务逻辑，甚至调用其他 skill；
• 真相：skill 应是原子操作，agent 负责编排。把逻辑塞进 skill，等于把大脑塞进手指；
• 解法：
  • Skill 接口严格限定：input: dict, output: dict；
  • Skill 内禁止调用其他 skill，禁止访问BeliefBase（只能读parameters）；
  • 所有决策逻辑，必须在IntentionPlanner或GoalManager中。

陷阱六：忽略人类反馈的闭环

• 现象：agent 做错，用户说“不对”，系统无反应；
• 真相：没把用户纠正当作PerceptionEvent，没触发BeliefRevision；
• 解法：
  • 用户说“错了”、“不是这个”、“重新来”，强制解析为semantic_type="correction"；
  • BeliefUpdater专门处理 correction：降低相关信念置信度，提高provenance为user_input的权重；
  • 我们加了feedback_sensitivity=0.9参数，用户一次纠正，相关信念置信度直接 ×0.1。

4.3 性能与成本实测对比：升级不是免费午餐，但 ROI 明确

我们拿一个真实电商比价 agent 做了 A/B 测试（相同硬件：A10 GPU × 2，Qwen-1.5B-Chat）：

指标	harness v1.2	Bolt 认知引擎	提升/变化
平均响应延迟	2.1s	2.8s	+33%（因多层契约校验）
端到端任务成功率	68.3%	91.7%	+23.4%
API 调用次数/会话	8.2	6.5	-20.7%（因意向规划减少无效调用）
LLM token 消耗/会话	1840	1520	-17.4%（因结构化输入减少冗余）
运维告警率（/天）	12.4	2.1	-83.1%（因契约拦截大部分错误）
新需求平均交付时间	5.0 天	2.8 天	-44%（因契约复用）

关键结论：延迟增加是可控代价，而稳定性、成功率、可维护性的提升是质变。尤其当业务从“单点问答”走向“多轮协作”，harness 的边际成本急剧上升，而认知工程的边际收益持续为正。我们测算，当 agent 日均会话 > 5000，Bolt 的 TCO（总拥有成本）比 harness 低 37%。

5. 认知工程的边界与未来：它不是万能药，而是新起点

把 harness 升级到认知工程，绝不是终点，而是一个更清醒的起点。我必须坦诚地说，它解决不了所有问题，甚至会暴露一些你以前没意识到的短板。

首先，认知工程极度依赖高质量的初始契约设计。如果你的PerceptionParser语义类型定义粗糙，或者GoalTemplate没覆盖核心业务流，那么整个认知循环就会在源头失准。我们曾在一个教育项目中，因为semantic_type没区分 “homework_help” 和 “exam_prep”，导致 agent 把高三冲刺复习当成日常作业辅导，推荐了完全错误的资料。这不是 Bolt 的 bug，而是契约设计的缺陷。所以，投入 30% 的时间在契约建模上，不是浪费，是必要投资。

其次，它放大了 LLM 的底层局限。认知工程让 agent 的推理链更透明，但也让 LLM 的幻觉、偏见、逻辑漏洞更无处遁形。当BeliefBase显示 “user.has_allergy=peanut” 来自tool_medical_record，而 LLM 在生成建议时却忽略了它，这个错误会被postconditions检查捕获，但根源还是 LLM。所以，认知工程必须搭配更强的 LLM 监控：我们在IntentionExecutor后加了LLMOutputValidator，用小模型二次校验关键事实（如过敏源、价格数字、时间日期），错误率再降 18%。

最后，也是最重要的，认知工程不是取代 human，而是重塑 human-agent 协作。当 agent 拥有了可解释的“心智”，产品经理不再问 “它为什么这么答”，而是问 “它的信念图谱里，哪条边的置信度该调高？”。开发者不再 debug “prompt 为什么失效”，而是 debug “precondition规则是否覆盖了这个边缘 case”。这要求团队具备新的能力栈：认知建模、信念