尧图网站开发 
实际做 AI 应用落地时最让人觉得难的往往不是模型效果本身而是从“用户说了一句话”到“系统真正完成一件事”之间那段漫长的链路。用户输入需要被感知、理解、补全上下文、做出决策、调用工具、执行动作最后还要依据反馈不断调整。任何一个环节断开整个交互都会失败。以人为本 AI 的六层连接框架正是为这段链路设计的一套分层规范从感知到行动拆成六个职责明确的层并通过统一的层间数据接口把它们连接起来让系统始终围绕用户目标工作。这套框架不是某一家厂商的专有产品也不是某个单一算法而是一种工程组织方式。它把 AI 系统中常见的模块抽成感知层、理解层、认知层、决策层、行动层和反馈层每一层只解决一个明确问题层与层之间通过结构化数据传递信息。只要接口约定清楚每一层都可以独立替换规则系统、传统机器学习、大模型调用、外部 API都可以作为某一层的实现。理解这一点再看 Agent 框架、LLM 应用开发或 RAG 系统都会更清楚它们分别落在哪一层。1. 六层连接框架要解决什么问题1.1 断裂的链路为什么模型很强产品却不好用单独看任何一个环节现在的技术储备都很充足。语音识别可以做得很准意图分类可以用大模型快速完成知识库检索有 RAG工具调用有各种 Agent 框架。但把这些能力拼到一起时问题就暴露出来了。最常见的问题是层间信息丢失。意图识别模块只返回了一个意图标签却没有把用户的地理位置、权限等级、历史偏好一起传下去决策模块拿到不完整的上下文自然无法制定正确的行动计划行动模块执行完接口调用系统只记录了“调用成功”却没有记录这次调用是否真的解决了用户的问题。于是每一层的局部指标都很高整体效果却很差。另一个问题是闭环缺失。系统执行完动作就结束了没有收集用户反馈没有把失败的案例写回记忆也没有形成下一次优化的样本。这样的系统只能算“能用”离“越用越准”还有很大距离。六层连接框架要解决的正是这类连接和闭环问题。1.2 以人为本的含义围绕用户目标而不是围绕模型指标“以人为本 AI”并不是一个营销词它有一个很实际的工程含义整个系统的每一层都应该服务于用户最终的目标而不是服务于模型自身的评测指标。以模型为中心的设计通常会优先考虑“意图识别准确率是否够高”“生成回复是否流畅”。以人为中心的设计则要额外回答几个问题用户的权限是否允许执行这次操作系统给出的行动是否可解释、可撤回用户不满意时系统如何记录并改进这些约束横跨多个层如果每一层各自为政就很容易出现“模型觉得答得很好用户却觉得完全没有解决”的情况。在六层框架里“以人为本”体现在两个地方。一是决策层需要把用户约束和权限规则作为硬边界不能为了完成任务而越权操作。二是反馈层必须把用户反馈作为系统的主动输入而不是事后统计。1.3 框架定位不是新算法而是层间连接规范这套框架最核心的价值是“连接”。它不限制某一层内部用什么技术也不规定必须用哪个大模型它只约定两件事每一层负责什么层与层之间传什么。这样做有三个实际收益。第一可追踪每个请求都有一个 request_id可以从感知一路追到反馈出问题时能快速定位是哪一层出了问题。第二可替换某层算法升级时只要输入输出格式不变就不影响其他层。第三可测试每一层都可以单独做单元测试也可以用同一组测试数据跑整个流水线做回归验证。2. 六层职责与层间数据流2.1 六层总览六个层的职责可以先用一张表说明清楚。层级核心问题输入输出常见实现手段感知层用户说了什么、来自哪里文本、语音、图片、事件统一的结构化感知事件语音转写、OCR、文件解析、消息队列理解层用户想干什么感知事件意图、领域、槽位、约束意图分类、NER、大模型结构化抽取认知层系统还知道哪些相关背景用户请求、当前上下文补全后的任务上下文会话记忆、知识库检索、用户画像决策层系统应该怎么做任务上下文行动计划、候选方案规划算法、规则引擎、LLM 推理行动层怎么能做成行动计划工具调用结果、对外回复工具注册中心、API 调用、代码执行反馈层结果是否符合用户预期执行结果、用户反馈反馈记录、记忆更新、评估指标评价打分、日志回放、人类标注这六层连起来就是一个从感知到行动的闭环。用户输入进入感知层经过理解、认知、决策、行动之后产生结果反馈层再把结果的好坏写回系统供下一次请求使用。可以用一个简单的 ASCII 图表示数据流向。用户输入 ↓ [感知层] → [理解层] → [认知层] → [决策层] → [行动层] → 用户侧结果 ↑ ↓ └──── [反馈层] ← 用户反馈实际项目里反馈层不仅接收用户显式反馈还接收行动层的执行日志、超时信息、错误码和埋点数据。2.2 感知层把真实世界的输入变成结构化事件感知层解决的是“输入不统一”的问题。用户可能发来一段文字、一条语音、一张截图也可能来自小程序、Web 页面、企业微信或客服系统。如果不做归一化后续每一层都要重新处理格式代码会迅速膨胀。感知层需要产出一个统一的事件对象至少包含请求 ID、输入模态、原始内容、时间、用户标识和渠道信息。示例结构如下。{ request_id: req_20250101_001, modality: text, content: 帮我把上周的销售数据按区域汇总一下, timestamp: 2025-01-01T10:00:00Z, meta: { user_id: u_1001, channel: web_chat, device: desktop } }这里的重点是把“模态度”和“元信息”从一开始就保留下来避免进入理解层之后还要回头去原始报文里找字段。2.3 理解层从文本到意图和槽位理解层的任务是把自然语言转换成结构化语义。它输出的不是一段回复而是机器可读的意图、领域、槽位和约束条件。{ request_id: req_20250101_001, intent: data_query, domain: sales, slots: { time_range: last_week, aggregation: by_region, target: sales_data }, constraints: { permission_required: sales:read }, confidence: 0.92 }理解层的输出必须带上约束信息。比如查询销售数据需要sales:read权限这个信息如果不在这里提取出来决策层就无法判断该用户的请求是否被允许。2.4 认知层上下文、记忆和知识认知层负责把“当前这句请求”放进“更大的背景”里。它要做三件事读取会话上下文检索相关知识更新用户模型。比如用户说“再帮我看看上周的”这里的“再”“上周”都依赖历史上下文。认知层需要把上一轮的条件补全成完整的查询条件再把销售知识库或数据字典里的字段映射关系带出来。认知层的输出是“补全后的任务上下文”它比理解层的输出更完整更适合决策层使用。2.5 决策层从判断到计划决策层是六层里最容易做坏的一层因为它要同时处理多个目标完成用户请求、遵守权限规则、控制风险、选择成本最低的方案。一个好的决策层输出是行动计划。行动计划要包含执行步骤、每个步骤用到的工具、关键参数和失败时的备选方案。{ plan_id: plan_001, steps: [ { action: query_database, params: { sql: SELECT region, SUM(amount) FROM sales WHERE date 2024-12-23 GROUP BY region } }, { action: format_table, params: { max_rows: 20 } }, { action: generate_reply, params: { style: concise } } ] }决策层需要能回答“为什么这样计划”。因此它生成的每一步最好都带上一个简短的依据说明方便反馈层和人工审计。2.6 行动层从计划到结果行动层负责真正执行。它维护一个工具注册中心把“工具名”映射到具体函数或 API。执行时要处理超时、重试、限流、幂等和错误码转换。行动层的特点是副作用大。查询数据是只读操作相对安全但发送邮件、创建订单、修改配置属于有副作用的操作必须记录完整的操作日志并且支持审计和回滚。行动层输出的是执行结果包括每一步是否成功、耗时、返回数据、错误信息。2.7 反馈层让系统越用越准反馈层是整个框架里最容易被忽略的一层。它接收执行结果、用户显式反馈、超时信息和埋点数据然后把这些信息转换成两类产出一类是记忆更新把“这个用户喜欢哪种回复风格”写回认知层另一类是评估记录把成功和失败案例汇总成可统计的指标。反馈层不一定要等用户点击“有用/没用”。行动层执行失败、用户快速关闭对话、同一问题反复提问都是隐性反馈。关键在于反馈数据必须能回流到具体某一层而不是只记录在一个没人看的日志文件里。3. 用最小实现跑通六层链路3.1 任务设定与目录结构为了把框架讲清楚这里用一个最小任务演示用户输入一句中文自然语言系统完成意图理解、上下文补全、计划生成、工具调用和反馈记录。代码用普通 Python 描述思路不绑定特定框架实际项目可以用 LangChain、Spring AI 或自研 pipeline 替换。学习环境目录结构可以这样安排。human_ai_framework/ ├── layers/ │ ├── perception.py │ ├── comprehension.py │ ├── cognition.py │ ├── decision.py │ ├── action.py │ └── feedback.py ├── tools/ │ ├── registry.py │ └── sales_query.py ├── pipeline.py └── main.py每一层文件只包含一个类输入输出都是统一的数据结构这样后续替换实现时不会牵动其他文件。3.2 感知层与理解层实现先定义层间传递的数据对象。这里用一个LayerMessage保留请求 ID、来源层、负载和追踪路径。# layers/message.py from __future__ import annotations from dataclasses import dataclass, field from typing import Any dataclass class LayerMessage: request_id: str source: str payload: dict[str, Any] trace: list[str] field(default_factorylist) def copy_to(self, source: str) - LayerMessage: return LayerMessage( request_idself.request_id, sourcesource, payloaddict(self.payload), tracelist(self.trace) [self.source], )感知层实现如下。它只做格式归一化不引入任何业务判断。# layers/perception.py from layers.message import LayerMessage class PerceptionLayer: def __call__(self, raw: dict) - LayerMessage: return LayerMessage( request_idraw.get(request_id, req_unknown), sourceperception, payload{ modality: raw.get(modality, text), content: (raw.get(content) or ).strip(), meta: { user_id: raw.get(user_id), channel: raw.get(channel, unknown), timestamp: raw.get(timestamp), }, }, )理解层在这个最小示例里先用规则实现意图识别生产环境再换成大模型结构化抽取。规则实现的好处是方便单测能明确看到输入输出变化。# layers/comprehension.py from layers.message import LayerMessage class ComprehensionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: text msg.payload[content] if (查 in text or 汇总 in text) and 数据 in text: intent data_query domain sales elif 写 in text or 生成 in text: intent content_generate domain general else: intent unknown domain general next_msg msg.copy_to(comprehension) next_msg.payload[intent] intent next_msg.payload[domain] domain next_msg.payload[confidence] 1.0 # 规则实现没有概率 return next_msg3.3 认知层与决策层实现认知层负责补全上下文。在最小例子里它把“上周”这种相对时间转成绝对时间范围并把销售表的可用字段一起放进任务上下文。# layers/cognition.py from datetime import date, timedelta from layers.message import LayerMessage class CognitionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: next_msg msg.copy_to(cognition) today date.today() last_monday today - timedelta(daystoday.weekday() 7) last_sunday last_monday timedelta(days6) next_msg.payload[context] { time_range: { start: last_monday.isoformat(), end: last_sunday.isoformat(), }, available_fields: [region, amount, date, sales_person], } return next_msg决策层根据意图生成行动计划。这里遵循一个简单原则只有intent为data_query时才允许查询数据库并且默认使用只读 SQL。# layers/decision.py from layers.message import LayerMessage class DecisionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: next_msg msg.copy_to(decision) if msg.payload.get(intent) ! data_query: next_msg.payload[plan] {action: explain_not_supported, params: {}} next_msg.payload[allowed] False return next_msg ctx msg.payload[context] next_msg.payload[allowed] True next_msg.payload[plan] { action: query_database, params: { sql: ( SELECT region, SUM(amount) AS total FROM sales fWHERE date {ctx[time_range][start]} fAND date {ctx[time_range][end]} GROUP BY region ) }, } return next_msg这里要注意决策层只生成计划不执行 SQL。把“制定计划”和“执行计划”分开是行动层安全设计的前提。3.4 行动层与反馈层实现行动层通过工具注册中心调用函数。先定义一个最简工具注册中心。# tools/registry.py from typing import Callable class ToolRegistry: def __init__(self) - None: self._tools: dict[str, Callable] {} def register(self, name: str, fn: Callable) - None: self._tools[name] fn def call(self, name: str, **kwargs): if name not in self._tools: raise KeyError(ftool not found: {name}) return self._tools[name](**kwargs)行动层接收决策层的计划执行工具并把执行结果和耗时记录到负载里。# layers/action.py import time from layers.message import LayerMessage from tools.registry import ToolRegistry class ActionLayer: def __init__(self, registry: ToolRegistry) - None: self.registry registry def __call__(self, msg: LayerMessage) - LayerMessage: plan msg.payload.get(plan, {}) next_msg msg.copy_to(action) if not msg.payload.get(allowed): next_msg.payload[result] {status: rejected, data: None} return next_msg start time.time() try: data self.registry.call(plan[action], **plan[params]) result {status: success, data: data} except Exception as exc: result {status: error, error: str(exc)} finally: duration_ms (time.time() - start) * 1000 next_msg.payload[result] result next_msg.payload[duration_ms] round(duration_ms, 2) return next_msg反馈层把执行结果写进一个简单的日志列表。实际项目里这里应该接数据库、消息队列或监控系统。# layers/feedback.py from layers.message import LayerMessage class FeedbackLayer: def __init__(self) - None: self.records: list[dict] [] def __call__(self, msg: LayerMessage) - LayerMessage: result msg.payload.get(result, {}) self.records.append( { request_id: msg.request_id, intent: msg.payload.get(intent), status: result.get(status), duration_ms: msg.payload.get(duration_ms), trace: msg.trace [feedback], } ) return msg.copy_to(feedback)3.5 运行与验证最后在main.py里把六层串起来。# main.py from layers.perception import PerceptionLayer from layers.comprehension import ComprehensionLayer from layers.cognition import CognitionLayer from layers.decision import DecisionLayer from layers.action import ActionLayer from layers.feedback import FeedbackLayer from tools.registry import ToolRegistry def fake_sales_query(sql: str) - list[dict]: # 学习环境用固定数据代替真实数据库 del sql return [ {region: 华东, total: 182000.0}, {region: 华南, total: 145500.0}, {region: 华北, total: 131200.0}, ] def build_pipeline() - ...: registry ToolRegistry() registry.register(query_database, fake_sales_query) return { perception: PerceptionLayer(), comprehension: ComprehensionLayer(), cognition: CognitionLayer(), decision: DecisionLayer(), action: ActionLayer(registry), feedback: FeedbackLayer(), } def run(): layers build_pipeline() raw { request_id: req_001, modality: text, content: 帮我把上周的销售数据按区域汇总一下, user_id: u_1001, channel: web_chat, timestamp: 2025-01-01T10:00:00Z, } msg layers[perception](raw) msg layers[comprehension](msg) msg layers[cognition](msg) msg layers[decision](msg) msg layers[action](msg) msg layers[feedback](msg) print(trace:, msg.trace) print(intent:, msg.payload[intent]) print(result:, msg.payload[result]) if __name__ __main__: run()运行结果应类似下面这样。trace: [perception, comprehension, cognition, decision, action, feedback] intent: data_query result: {status: success, data: [{region: 华东, total: 182000.0}, {region: 华南, total: 145500.0}, {region: 华北, total: 131200.0}]}验证时不要只看程序能启动还要检查三条一是 trace 里是否完整包含六个层二是同一个请求经过六层后 request_id 是否保持一致三是把输入改成无权限请求确认决策层能返回 rejected而不是继续执行。4. 关键技术机制上下文、记忆、工具与人在回路4.1 上下文生命周期管理上下文是六层框架里最容易失控的字段。每一层都可能往负载里追加数据如果没人清理经过几轮对话后负载会越来越臃肿大模型输入也会超过长度限制。推荐的管理方式只有一条明确上下文的生命周期。请求级上下文跟着 request_id 走请求结束就释放会话级上下文按 session_id 存储并设置过期时间用户级上下文属于长期数据需要走数据库并考虑隐私合规。在代码层面每一层应该只追加自己产生的字段不要修改其他层的字段。4.2 记忆分层的落地方式记忆可以分成三个层次短期记忆、长期记忆和外部知识。短期记忆就是最近几轮对话内容可以放在内存或 Redis 中长期记忆是用户偏好、历史决策结果需要结构化存储外部知识是业务文档、数据库字典、内部知识库通常通过向量检索或 SQL 查询获取。在六层框架里记忆主要服务于认知层。认知层在做“任务补全”时需要同时读取这三类记忆并把结果合并进任务上下文。这里要特别小心检索到的知识并不一定正确需要在任务上下文中标注来源和置信度方便决策层和反馈层判断。4.3 工具调用的安全边界行动层是副作用集中发生的地方安全设计必须前置。最少权限原则要落实在工具注册中心注册工具时同时注册该工具需要的权限标识调用前先做权限校验。registry.register( send_email, send_email, permissionemail:send, idempotentFalse, )权限不足时返回明确的拒绝原因而不是直接抛出底层异常。除此之外还要考虑幂等设计。创建订单、发送通知这类操作如果被重复执行会产生严重问题因此行动层需要把请求 ID 作为幂等键传给工具工具内部做去重。4.4 反馈怎么回流到系统反馈层要形成真正的闭环至少需要三条回流路径。第一条是回写记忆把用户当前偏好更新到认知层的用户画像中第二条是生成训练或评测样本把成功的决策链路和失败的决策链路分别归档第三条是触发告警当某一层的失败率超过阈值时通知开发人员介入。实际项目里反馈数据要先经过清洗再入库。用户说“不好”可能是对内容不满意也可能只是误触。至少要记录上下文快照、当时的决策计划、行动结果和用户反馈原文这样后续分析时才能还原现场。5. 每一层常见坑与排查路径5.1 感知层输入格式不正确现象是理解层拿到的 content 为空或者 JSON 解析报错。常见原因是感知层过早丢弃了原始字段或者对空输入没有做兜底。排查时先检查感知层输出的 LayerMessage确认 content、meta、request_id 都存在再往上层追。修复方法是在感知层对空文本、超长文本和无法识别的文件类型做明确处理并记录一条rejected日志。5.2 理解与决策层意图漂移和权限遗漏现象是用户明明说得很清楚系统却把意图识别错或者决策层生成了一个没有权限检查的计划。意图漂移多发生在规则实现或小模型上遇到新说法就失效。解决方法是保留一份测试集每次调整理解层后都跑一遍回归。权限遗漏则更危险命令规范是决策层永远不要把 “allowed” 默认成 true必须显式初始化。5.3 行动层工具调用失败和副作用重复现象是工具抛错但错误信息被吞掉只返回一个空的 success。常见原因是行动层 catch 了异常却没有保留堆栈或者没有检查工具返回值是否真的符合预期。排查时看result.status和error字段确认异常类型和堆栈能被追踪到。预防手段是给每个工具定义独立的错误码超时、限流、参数错误要分开记录。5.4 反馈层指标失真和回流中断现象是反馈记录很多但系统没有任何改进。常见原因是反馈数据只写日志没有回流到记忆或评测链路。排查时先确认反馈层的 records 是否真的写入了存储再确认认知层是否读取了这些记录。反馈回流中断往往不是代码问题而是链路设计时漏掉了消费端。可以按下面这张表快速定位。问题现象可能层级检查方式处理建议输入丢字段感知层打印感知层输出在入口做归一化和空值兜底意图不对理解层跑测试集看识别结果补充样本或升级为 LLM 抽取上下文不完整认知层看补全后的 payload检查记忆读取和知识检索没有权限也执行决策层检查 allowed 字段对所有计划做权限预校验工具报错不直观行动层看错误码和堆栈定义工具级错误码反馈没有生效反馈层检查消费端是否接入把反馈与记忆、评测打通6. 从学习环境到生产环境6.1 学习环境怎么快速跑通学习环境的目标是理解链路不是追求生产级稳定性。上面的最小实现已经能跑通闭环。建议在此基础上做三个练习一是增加一个需要权限拦截的工具比如发送邮件观察决策层如何拒绝二是把理解层从规则换成一次大模型结构化抽取对比输入输出格式是否仍然兼容三是给反馈层增加一个简单统计统计过去一百次请求的成功率。这三个练习做完基本就掌握了六层框架的连接方式。6.2 生产环境必备保障生产环境不是把学习代码原样部署至少还要补齐以下能力。配置外置化模型 API 地址、数据库连接、权限规则都要放到配置中心不能写死在代码里。日志与监控每一层都要输出结构化日志包含 request_id、耗时、状态和关键字段对成功率、耗时、工具错误率设置告警。权限与审计有副作用的工具调用必须记录操作人、操作对象、执行时间和结果支持事后审计。异常与回滚行动层的所有写操作都要考虑回滚方案生成计划前先做规则校验。版本兼容理解层从规则升级为大模型后测试集要保留接口格式不能突变。数据备份反馈记录、用户画像和记忆数据要定期备份避免误删后无法恢复。自动化测试也要提上日程。感知层可以跑格式校验测试理解层可以跑意图分类回归测试行动层可以跑工具 mock 测试。类似 pytest 这类测试框架在这套分层结构里很好落地因为每一层输入输出都是纯数据结构便于构造 fixture。6.3 上线顺序与灰度策略上线时不要一次把所有层都换成大模型方案。推荐从低风险层开始先上线感知层和行动层因为这两个层偏工程边界清晰然后上线认知层引入记忆和知识检索最后再替换理解层和决策层因为它们直接决定用户体验风险最高。灰度阶段要保留新旧两套链路用同一个请求同时跑对比 intent、plan 和 result 的差异。差异率收敛之后再把流量全量切到新链路。7. 可复用清单与扩展方向7.1 六层设计检查清单无论是新项目还是已有系统重构都可以用下面的清单做自检。每一层是否有明确的输入输出类型并且层间只通过结构体传递。每个请求是否都有唯一的 request_id并且在六层中保持一致。感知层是否处理了空输入、超长输入和未知模态。理解层输出的意图、槽位和约束是否足够决策层使用。认知层是否区分短期记忆、长期记忆和外部知识。决策层是否对所有计划做了权限预校验拒绝时是否有明确原因。行动层是否注册了工具权限、幂等键和错误码。反馈层是否有回流路径而不仅仅是写日志。所有层是否都有结构化日志并能按 request_id 串联。有无一套回归测试集能在任意层替换后快速验证。7.2 扩展方向六层框架最值得扩展的方向有三个。第一多智能体协作。当单一决策层无法解决复杂任务时可以把决策层扩展成调度器由它分配多个子智能体并行处理每个子智能体内部仍然是感知、理解、决策、行动的简化循环。第二评估体系完善。反馈层可以升级为系统性评估平台把用户反馈、机器评分、人工标注和线上指标统一到一个面板为每一层的替换提供数据依据。第三人与 AI 的协同界面。以人为本 AI 不仅要处理完整任务还要能在不确定时主动向用户提问、展示计划并请求确认。这些交互都发生在决策层和行动层之间本质上是在链路中增加“人在回路”的显式节点。对新手来说最有价值的练习不是急着接入最贵的大模型而是先用最小链条把六层跑通再逐步替换其中某一层的实现。真正决定一个 AI 应用上限的往往不是单点模型能力而是感知到行动之间这条链路是否完整、是否可追踪、是否能够在反馈中持续改进。 
实际做 AI 应用落地时最让人觉得难的往往不是模型效果本身而是从“用户说了一句话”到“系统真正完成一件事”之间那段漫长的链路。用户输入需要被感知、理解、补全上下文、做出决策、调用工具、执行动作最后还要依据反馈不断调整。任何一个环节断开整个交互都会失败。以人为本 AI 的六层连接框架正是为这段链路设计的一套分层规范从感知到行动拆成六个职责明确的层并通过统一的层间数据接口把它们连接起来让系统始终围绕用户目标工作。这套框架不是某一家厂商的专有产品也不是某个单一算法而是一种工程组织方式。它把 AI 系统中常见的模块抽成感知层、理解层、认知层、决策层、行动层和反馈层每一层只解决一个明确问题层与层之间通过结构化数据传递信息。只要接口约定清楚每一层都可以独立替换规则系统、传统机器学习、大模型调用、外部 API都可以作为某一层的实现。理解这一点再看 Agent 框架、LLM 应用开发或 RAG 系统都会更清楚它们分别落在哪一层。1. 六层连接框架要解决什么问题1.1 断裂的链路为什么模型很强产品却不好用单独看任何一个环节现在的技术储备都很充足。语音识别可以做得很准意图分类可以用大模型快速完成知识库检索有 RAG工具调用有各种 Agent 框架。但把这些能力拼到一起时问题就暴露出来了。最常见的问题是层间信息丢失。意图识别模块只返回了一个意图标签却没有把用户的地理位置、权限等级、历史偏好一起传下去决策模块拿到不完整的上下文自然无法制定正确的行动计划行动模块执行完接口调用系统只记录了“调用成功”却没有记录这次调用是否真的解决了用户的问题。于是每一层的局部指标都很高整体效果却很差。另一个问题是闭环缺失。系统执行完动作就结束了没有收集用户反馈没有把失败的案例写回记忆也没有形成下一次优化的样本。这样的系统只能算“能用”离“越用越准”还有很大距离。六层连接框架要解决的正是这类连接和闭环问题。1.2 以人为本的含义围绕用户目标而不是围绕模型指标“以人为本 AI”并不是一个营销词它有一个很实际的工程含义整个系统的每一层都应该服务于用户最终的目标而不是服务于模型自身的评测指标。以模型为中心的设计通常会优先考虑“意图识别准确率是否够高”“生成回复是否流畅”。以人为中心的设计则要额外回答几个问题用户的权限是否允许执行这次操作系统给出的行动是否可解释、可撤回用户不满意时系统如何记录并改进这些约束横跨多个层如果每一层各自为政就很容易出现“模型觉得答得很好用户却觉得完全没有解决”的情况。在六层框架里“以人为本”体现在两个地方。一是决策层需要把用户约束和权限规则作为硬边界不能为了完成任务而越权操作。二是反馈层必须把用户反馈作为系统的主动输入而不是事后统计。1.3 框架定位不是新算法而是层间连接规范这套框架最核心的价值是“连接”。它不限制某一层内部用什么技术也不规定必须用哪个大模型它只约定两件事每一层负责什么层与层之间传什么。这样做有三个实际收益。第一可追踪每个请求都有一个 request_id可以从感知一路追到反馈出问题时能快速定位是哪一层出了问题。第二可替换某层算法升级时只要输入输出格式不变就不影响其他层。第三可测试每一层都可以单独做单元测试也可以用同一组测试数据跑整个流水线做回归验证。2. 六层职责与层间数据流2.1 六层总览六个层的职责可以先用一张表说明清楚。层级核心问题输入输出常见实现手段感知层用户说了什么、来自哪里文本、语音、图片、事件统一的结构化感知事件语音转写、OCR、文件解析、消息队列理解层用户想干什么感知事件意图、领域、槽位、约束意图分类、NER、大模型结构化抽取认知层系统还知道哪些相关背景用户请求、当前上下文补全后的任务上下文会话记忆、知识库检索、用户画像决策层系统应该怎么做任务上下文行动计划、候选方案规划算法、规则引擎、LLM 推理行动层怎么能做成行动计划工具调用结果、对外回复工具注册中心、API 调用、代码执行反馈层结果是否符合用户预期执行结果、用户反馈反馈记录、记忆更新、评估指标评价打分、日志回放、人类标注这六层连起来就是一个从感知到行动的闭环。用户输入进入感知层经过理解、认知、决策、行动之后产生结果反馈层再把结果的好坏写回系统供下一次请求使用。可以用一个简单的 ASCII 图表示数据流向。用户输入 ↓ [感知层] → [理解层] → [认知层] → [决策层] → [行动层] → 用户侧结果 ↑ ↓ └──── [反馈层] ← 用户反馈实际项目里反馈层不仅接收用户显式反馈还接收行动层的执行日志、超时信息、错误码和埋点数据。2.2 感知层把真实世界的输入变成结构化事件感知层解决的是“输入不统一”的问题。用户可能发来一段文字、一条语音、一张截图也可能来自小程序、Web 页面、企业微信或客服系统。如果不做归一化后续每一层都要重新处理格式代码会迅速膨胀。感知层需要产出一个统一的事件对象至少包含请求 ID、输入模态、原始内容、时间、用户标识和渠道信息。示例结构如下。{ request_id: req_20250101_001, modality: text, content: 帮我把上周的销售数据按区域汇总一下, timestamp: 2025-01-01T10:00:00Z, meta: { user_id: u_1001, channel: web_chat, device: desktop } }这里的重点是把“模态度”和“元信息”从一开始就保留下来避免进入理解层之后还要回头去原始报文里找字段。2.3 理解层从文本到意图和槽位理解层的任务是把自然语言转换成结构化语义。它输出的不是一段回复而是机器可读的意图、领域、槽位和约束条件。{ request_id: req_20250101_001, intent: data_query, domain: sales, slots: { time_range: last_week, aggregation: by_region, target: sales_data }, constraints: { permission_required: sales:read }, confidence: 0.92 }理解层的输出必须带上约束信息。比如查询销售数据需要sales:read权限这个信息如果不在这里提取出来决策层就无法判断该用户的请求是否被允许。2.4 认知层上下文、记忆和知识认知层负责把“当前这句请求”放进“更大的背景”里。它要做三件事读取会话上下文检索相关知识更新用户模型。比如用户说“再帮我看看上周的”这里的“再”“上周”都依赖历史上下文。认知层需要把上一轮的条件补全成完整的查询条件再把销售知识库或数据字典里的字段映射关系带出来。认知层的输出是“补全后的任务上下文”它比理解层的输出更完整更适合决策层使用。2.5 决策层从判断到计划决策层是六层里最容易做坏的一层因为它要同时处理多个目标完成用户请求、遵守权限规则、控制风险、选择成本最低的方案。一个好的决策层输出是行动计划。行动计划要包含执行步骤、每个步骤用到的工具、关键参数和失败时的备选方案。{ plan_id: plan_001, steps: [ { action: query_database, params: { sql: SELECT region, SUM(amount) FROM sales WHERE date 2024-12-23 GROUP BY region } }, { action: format_table, params: { max_rows: 20 } }, { action: generate_reply, params: { style: concise } } ] }决策层需要能回答“为什么这样计划”。因此它生成的每一步最好都带上一个简短的依据说明方便反馈层和人工审计。2.6 行动层从计划到结果行动层负责真正执行。它维护一个工具注册中心把“工具名”映射到具体函数或 API。执行时要处理超时、重试、限流、幂等和错误码转换。行动层的特点是副作用大。查询数据是只读操作相对安全但发送邮件、创建订单、修改配置属于有副作用的操作必须记录完整的操作日志并且支持审计和回滚。行动层输出的是执行结果包括每一步是否成功、耗时、返回数据、错误信息。2.7 反馈层让系统越用越准反馈层是整个框架里最容易被忽略的一层。它接收执行结果、用户显式反馈、超时信息和埋点数据然后把这些信息转换成两类产出一类是记忆更新把“这个用户喜欢哪种回复风格”写回认知层另一类是评估记录把成功和失败案例汇总成可统计的指标。反馈层不一定要等用户点击“有用/没用”。行动层执行失败、用户快速关闭对话、同一问题反复提问都是隐性反馈。关键在于反馈数据必须能回流到具体某一层而不是只记录在一个没人看的日志文件里。3. 用最小实现跑通六层链路3.1 任务设定与目录结构为了把框架讲清楚这里用一个最小任务演示用户输入一句中文自然语言系统完成意图理解、上下文补全、计划生成、工具调用和反馈记录。代码用普通 Python 描述思路不绑定特定框架实际项目可以用 LangChain、Spring AI 或自研 pipeline 替换。学习环境目录结构可以这样安排。human_ai_framework/ ├── layers/ │ ├── perception.py │ ├── comprehension.py │ ├── cognition.py │ ├── decision.py │ ├── action.py │ └── feedback.py ├── tools/ │ ├── registry.py │ └── sales_query.py ├── pipeline.py └── main.py每一层文件只包含一个类输入输出都是统一的数据结构这样后续替换实现时不会牵动其他文件。3.2 感知层与理解层实现先定义层间传递的数据对象。这里用一个LayerMessage保留请求 ID、来源层、负载和追踪路径。# layers/message.py from __future__ import annotations from dataclasses import dataclass, field from typing import Any dataclass class LayerMessage: request_id: str source: str payload: dict[str, Any] trace: list[str] field(default_factorylist) def copy_to(self, source: str) - LayerMessage: return LayerMessage( request_idself.request_id, sourcesource, payloaddict(self.payload), tracelist(self.trace) [self.source], )感知层实现如下。它只做格式归一化不引入任何业务判断。# layers/perception.py from layers.message import LayerMessage class PerceptionLayer: def __call__(self, raw: dict) - LayerMessage: return LayerMessage( request_idraw.get(request_id, req_unknown), sourceperception, payload{ modality: raw.get(modality, text), content: (raw.get(content) or ).strip(), meta: { user_id: raw.get(user_id), channel: raw.get(channel, unknown), timestamp: raw.get(timestamp), }, }, )理解层在这个最小示例里先用规则实现意图识别生产环境再换成大模型结构化抽取。规则实现的好处是方便单测能明确看到输入输出变化。# layers/comprehension.py from layers.message import LayerMessage class ComprehensionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: text msg.payload[content] if (查 in text or 汇总 in text) and 数据 in text: intent data_query domain sales elif 写 in text or 生成 in text: intent content_generate domain general else: intent unknown domain general next_msg msg.copy_to(comprehension) next_msg.payload[intent] intent next_msg.payload[domain] domain next_msg.payload[confidence] 1.0 # 规则实现没有概率 return next_msg3.3 认知层与决策层实现认知层负责补全上下文。在最小例子里它把“上周”这种相对时间转成绝对时间范围并把销售表的可用字段一起放进任务上下文。# layers/cognition.py from datetime import date, timedelta from layers.message import LayerMessage class CognitionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: next_msg msg.copy_to(cognition) today date.today() last_monday today - timedelta(daystoday.weekday() 7) last_sunday last_monday timedelta(days6) next_msg.payload[context] { time_range: { start: last_monday.isoformat(), end: last_sunday.isoformat(), }, available_fields: [region, amount, date, sales_person], } return next_msg决策层根据意图生成行动计划。这里遵循一个简单原则只有intent为data_query时才允许查询数据库并且默认使用只读 SQL。# layers/decision.py from layers.message import LayerMessage class DecisionLayer: def __call__(self, msg: LayerMessage) - LayerMessage: next_msg msg.copy_to(decision) if msg.payload.get(intent) ! data_query: next_msg.payload[plan] {action: explain_not_supported, params: {}} next_msg.payload[allowed] False return next_msg ctx msg.payload[context] next_msg.payload[allowed] True next_msg.payload[plan] { action: query_database, params: { sql: ( SELECT region, SUM(amount) AS total FROM sales fWHERE date {ctx[time_range][start]} fAND date {ctx[time_range][end]} GROUP BY region ) }, } return next_msg这里要注意决策层只生成计划不执行 SQL。把“制定计划”和“执行计划”分开是行动层安全设计的前提。3.4 行动层与反馈层实现行动层通过工具注册中心调用函数。先定义一个最简工具注册中心。# tools/registry.py from typing import Callable class ToolRegistry: def __init__(self) - None: self._tools: dict[str, Callable] {} def register(self, name: str, fn: Callable) - None: self._tools[name] fn def call(self, name: str, **kwargs): if name not in self._tools: raise KeyError(ftool not found: {name}) return self._tools[name](**kwargs)行动层接收决策层的计划执行工具并把执行结果和耗时记录到负载里。# layers/action.py import time from layers.message import LayerMessage from tools.registry import ToolRegistry class ActionLayer: def __init__(self, registry: ToolRegistry) - None: self.registry registry def __call__(self, msg: LayerMessage) - LayerMessage: plan msg.payload.get(plan, {}) next_msg msg.copy_to(action) if not msg.payload.get(allowed): next_msg.payload[result] {status: rejected, data: None} return next_msg start time.time() try: data self.registry.call(plan[action], **plan[params]) result {status: success, data: data} except Exception as exc: result {status: error, error: str(exc)} finally: duration_ms (time.time() - start) * 1000 next_msg.payload[result] result next_msg.payload[duration_ms] round(duration_ms, 2) return next_msg反馈层把执行结果写进一个简单的日志列表。实际项目里这里应该接数据库、消息队列或监控系统。# layers/feedback.py from layers.message import LayerMessage class FeedbackLayer: def __init__(self) - None: self.records: list[dict] [] def __call__(self, msg: LayerMessage) - LayerMessage: result msg.payload.get(result, {}) self.records.append( { request_id: msg.request_id, intent: msg.payload.get(intent), status: result.get(status), duration_ms: msg.payload.get(duration_ms), trace: msg.trace [feedback], } ) return msg.copy_to(feedback)3.5 运行与验证最后在main.py里把六层串起来。# main.py from layers.perception import PerceptionLayer from layers.comprehension import ComprehensionLayer from layers.cognition import CognitionLayer from layers.decision import DecisionLayer from layers.action import ActionLayer from layers.feedback import FeedbackLayer from tools.registry import ToolRegistry def fake_sales_query(sql: str) - list[dict]: # 学习环境用固定数据代替真实数据库 del sql return [ {region: 华东, total: 182000.0}, {region: 华南, total: 145500.0}, {region: 华北, total: 131200.0}, ] def build_pipeline() - ...: registry ToolRegistry() registry.register(query_database, fake_sales_query) return { perception: PerceptionLayer(), comprehension: ComprehensionLayer(), cognition: CognitionLayer(), decision: DecisionLayer(), action: ActionLayer(registry), feedback: FeedbackLayer(), } def run(): layers build_pipeline() raw { request_id: req_001, modality: text, content: 帮我把上周的销售数据按区域汇总一下, user_id: u_1001, channel: web_chat, timestamp: 2025-01-01T10:00:00Z, } msg layers[perception](raw) msg layers[comprehension](msg) msg layers[cognition](msg) msg layers[decision](msg) msg layers[action](msg) msg layers[feedback](msg) print(trace:, msg.trace) print(intent:, msg.payload[intent]) print(result:, msg.payload[result]) if __name__ __main__: run()运行结果应类似下面这样。trace: [perception, comprehension, cognition, decision, action, feedback] intent: data_query result: {status: success, data: [{region: 华东, total: 182000.0}, {region: 华南, total: 145500.0}, {region: 华北, total: 131200.0}]}验证时不要只看程序能启动还要检查三条一是 trace 里是否完整包含六个层二是同一个请求经过六层后 request_id 是否保持一致三是把输入改成无权限请求确认决策层能返回 rejected而不是继续执行。4. 关键技术机制上下文、记忆、工具与人在回路4.1 上下文生命周期管理上下文是六层框架里最容易失控的字段。每一层都可能往负载里追加数据如果没人清理经过几轮对话后负载会越来越臃肿大模型输入也会超过长度限制。推荐的管理方式只有一条明确上下文的生命周期。请求级上下文跟着 request_id 走请求结束就释放会话级上下文按 session_id 存储并设置过期时间用户级上下文属于长期数据需要走数据库并考虑隐私合规。在代码层面每一层应该只追加自己产生的字段不要修改其他层的字段。4.2 记忆分层的落地方式记忆可以分成三个层次短期记忆、长期记忆和外部知识。短期记忆就是最近几轮对话内容可以放在内存或 Redis 中长期记忆是用户偏好、历史决策结果需要结构化存储外部知识是业务文档、数据库字典、内部知识库通常通过向量检索或 SQL 查询获取。在六层框架里记忆主要服务于认知层。认知层在做“任务补全”时需要同时读取这三类记忆并把结果合并进任务上下文。这里要特别小心检索到的知识并不一定正确需要在任务上下文中标注来源和置信度方便决策层和反馈层判断。4.3 工具调用的安全边界行动层是副作用集中发生的地方安全设计必须前置。最少权限原则要落实在工具注册中心注册工具时同时注册该工具需要的权限标识调用前先做权限校验。registry.register( send_email, send_email, permissionemail:send, idempotentFalse, )权限不足时返回明确的拒绝原因而不是直接抛出底层异常。除此之外还要考虑幂等设计。创建订单、发送通知这类操作如果被重复执行会产生严重问题因此行动层需要把请求 ID 作为幂等键传给工具工具内部做去重。4.4 反馈怎么回流到系统反馈层要形成真正的闭环至少需要三条回流路径。第一条是回写记忆把用户当前偏好更新到认知层的用户画像中第二条是生成训练或评测样本把成功的决策链路和失败的决策链路分别归档第三条是触发告警当某一层的失败率超过阈值时通知开发人员介入。实际项目里反馈数据要先经过清洗再入库。用户说“不好”可能是对内容不满意也可能只是误触。至少要记录上下文快照、当时的决策计划、行动结果和用户反馈原文这样后续分析时才能还原现场。5. 每一层常见坑与排查路径5.1 感知层输入格式不正确现象是理解层拿到的 content 为空或者 JSON 解析报错。常见原因是感知层过早丢弃了原始字段或者对空输入没有做兜底。排查时先检查感知层输出的 LayerMessage确认 content、meta、request_id 都存在再往上层追。修复方法是在感知层对空文本、超长文本和无法识别的文件类型做明确处理并记录一条rejected日志。5.2 理解与决策层意图漂移和权限遗漏现象是用户明明说得很清楚系统却把意图识别错或者决策层生成了一个没有权限检查的计划。意图漂移多发生在规则实现或小模型上遇到新说法就失效。解决方法是保留一份测试集每次调整理解层后都跑一遍回归。权限遗漏则更危险命令规范是决策层永远不要把 “allowed” 默认成 true必须显式初始化。5.3 行动层工具调用失败和副作用重复现象是工具抛错但错误信息被吞掉只返回一个空的 success。常见原因是行动层 catch 了异常却没有保留堆栈或者没有检查工具返回值是否真的符合预期。排查时看result.status和error字段确认异常类型和堆栈能被追踪到。预防手段是给每个工具定义独立的错误码超时、限流、参数错误要分开记录。5.4 反馈层指标失真和回流中断现象是反馈记录很多但系统没有任何改进。常见原因是反馈数据只写日志没有回流到记忆或评测链路。排查时先确认反馈层的 records 是否真的写入了存储再确认认知层是否读取了这些记录。反馈回流中断往往不是代码问题而是链路设计时漏掉了消费端。可以按下面这张表快速定位。问题现象可能层级检查方式处理建议输入丢字段感知层打印感知层输出在入口做归一化和空值兜底意图不对理解层跑测试集看识别结果补充样本或升级为 LLM 抽取上下文不完整认知层看补全后的 payload检查记忆读取和知识检索没有权限也执行决策层检查 allowed 字段对所有计划做权限预校验工具报错不直观行动层看错误码和堆栈定义工具级错误码反馈没有生效反馈层检查消费端是否接入把反馈与记忆、评测打通6. 从学习环境到生产环境6.1 学习环境怎么快速跑通学习环境的目标是理解链路不是追求生产级稳定性。上面的最小实现已经能跑通闭环。建议在此基础上做三个练习一是增加一个需要权限拦截的工具比如发送邮件观察决策层如何拒绝二是把理解层从规则换成一次大模型结构化抽取对比输入输出格式是否仍然兼容三是给反馈层增加一个简单统计统计过去一百次请求的成功率。这三个练习做完基本就掌握了六层框架的连接方式。6.2 生产环境必备保障生产环境不是把学习代码原样部署至少还要补齐以下能力。配置外置化模型 API 地址、数据库连接、权限规则都要放到配置中心不能写死在代码里。日志与监控每一层都要输出结构化日志包含 request_id、耗时、状态和关键字段对成功率、耗时、工具错误率设置告警。权限与审计有副作用的工具调用必须记录操作人、操作对象、执行时间和结果支持事后审计。异常与回滚行动层的所有写操作都要考虑回滚方案生成计划前先做规则校验。版本兼容理解层从规则升级为大模型后测试集要保留接口格式不能突变。数据备份反馈记录、用户画像和记忆数据要定期备份避免误删后无法恢复。自动化测试也要提上日程。感知层可以跑格式校验测试理解层可以跑意图分类回归测试行动层可以跑工具 mock 测试。类似 pytest 这类测试框架在这套分层结构里很好落地因为每一层输入输出都是纯数据结构便于构造 fixture。6.3 上线顺序与灰度策略上线时不要一次把所有层都换成大模型方案。推荐从低风险层开始先上线感知层和行动层因为这两个层偏工程边界清晰然后上线认知层引入记忆和知识检索最后再替换理解层和决策层因为它们直接决定用户体验风险最高。灰度阶段要保留新旧两套链路用同一个请求同时跑对比 intent、plan 和 result 的差异。差异率收敛之后再把流量全量切到新链路。7. 可复用清单与扩展方向7.1 六层设计检查清单无论是新项目还是已有系统重构都可以用下面的清单做自检。每一层是否有明确的输入输出类型并且层间只通过结构体传递。每个请求是否都有唯一的 request_id并且在六层中保持一致。感知层是否处理了空输入、超长输入和未知模态。理解层输出的意图、槽位和约束是否足够决策层使用。认知层是否区分短期记忆、长期记忆和外部知识。决策层是否对所有计划做了权限预校验拒绝时是否有明确原因。行动层是否注册了工具权限、幂等键和错误码。反馈层是否有回流路径而不仅仅是写日志。所有层是否都有结构化日志并能按 request_id 串联。有无一套回归测试集能在任意层替换后快速验证。7.2 扩展方向六层框架最值得扩展的方向有三个。第一多智能体协作。当单一决策层无法解决复杂任务时可以把决策层扩展成调度器由它分配多个子智能体并行处理每个子智能体内部仍然是感知、理解、决策、行动的简化循环。第二评估体系完善。反馈层可以升级为系统性评估平台把用户反馈、机器评分、人工标注和线上指标统一到一个面板为每一层的替换提供数据依据。第三人与 AI 的协同界面。以人为本 AI 不仅要处理完整任务还要能在不确定时主动向用户提问、展示计划并请求确认。这些交互都发生在决策层和行动层之间本质上是在链路中增加“人在回路”的显式节点。对新手来说最有价值的练习不是急着接入最贵的大模型而是先用最小链条把六层跑通再逐步替换其中某一层的实现。真正决定一个 AI 应用上限的往往不是单点模型能力而是感知到行动之间这条链路是否完整、是否可追踪、是否能够在反馈中持续改进。