Kriki Agent 学习室 TEAM LEARNING / 01
Agent 原理与框架 UPDATED

它不是会聊天，而是会围绕目标持续做事。

从“数字员工”的直觉开始，逐步看懂 Token、Context、工具、Runtime、记忆和治理如何组成一个真正可运行的 Agent，并把这些原理映射回 Kriki。

01 / 建立直觉

先把 Agent 想成一名数字员工。

模型像大脑；Agent 拥有目标、工具、工作状态和持续反馈，能够把“知道”变成“完成”。

Agent 是一个能够围绕目标，自己判断下一步、调用工具做事，并根据结果继续调整的 AI 系统。关键不在于“用了 AI”，而在于目标、行动、观察和再决策形成闭环。
Diagram 01 · Goal Loop用户给出目标之后，Agent 如何持续推进
用户目标说明想要的结果，而不是指定每一步
→
思考下一步结合当前 Context 判断最合适的行动
→
调用工具由 Runtime 校验后执行真实动作
→
观察结果读取工具返回的事实与环境变化
→
目标完成？完成则交付；未完成则调整路线
未完成：把 Observation 放回 Context，继续判断
Agent 不是一次回答，而是一个受 Runtime 管理的 Action–Observation 循环。

大模型像“大脑”

理解语言、分析信息、生成判断。但它本身不会长期运行，也不会亲自操作日历、文档或设备。

Agent 像“数字员工”

接收目标、选择行动、使用工具、读取结果，发现路线不对时调整，直到完成或触发停止条件。

人类员工Agent
理解领导交代的目标理解用户输入的任务
思考接下来做什么模型判断下一步行动
使用电脑、软件和资料调用搜索、日历、文档与设备工具
查看执行结果读取工具返回的 Observation
发现不对就调整根据结果继续判断、重试或询问用户
02 / 名词地图

从 Token 到 Agent，每一层解决不同问题。

热词不是升级关卡。模型负责生成，Context 负责组织信息，工具负责连接外部世界，Runtime 负责连续运行。

LLM + Token

Transformer 基于当前输入逐 Token 生成下一段内容。

推理与生成
Context + Prompt + RAG

组织本次判断真正需要看到的目标、历史、状态、知识与规则。

临时工作台
Tools + Function Calling

模型表达工具选择与参数，Runtime 才真实执行。

行动能力
MCP / API / CLI

解决能力如何接入，不替代推理、授权和规划。

连接方式
Runtime + Loop

持续组织 Context、保存 State、观察结果、控制风险与停止。

运行骨架
Context Window这一次模型看见什么
Kriki今天恢复78%会议训练计划
System Prompt
角色与边界
User Goal
当前目标
State
进度与计划
Memory
偏好与规律
RAG
外部证据
Tool Result
真实观察

Context 不是聊天记录的别名。它是本次调用实际可见的全部输入；窗口越大，也越需要筛选和压缩。

Diagram 02A · Prompt & Context Controls控制模型怎么表达，不等于保证系统正确执行
CONTROL / 01System Prompt定义角色、规则、权限与表达边界。不能突破系统能力与授权
CONTROL / 02Few-Shot用少量示例说明判断标准与输出模式。提高稳定性，不锁死格式
CONTROL / 03Prefill在支持的模型中预设回答开头，引导后续生成。不能保证 JSON 合法
CONTROL / 04Stop Sequence命中特定文本时停止继续解码。Agent 停止仍由 Runtime 决定
Prompt 是 Context 的一部分。生产系统仍需 Schema 校验、真实工具回读、预算与停止条件；不能把“模型按格式输出”误认为“业务已经正确执行”。
03 / RAG 基础

需要时查证据，而不是把整本书塞给模型。

RAG 在运行时检索相关资料，把证据放进本次 Context；它不修改模型参数，也不等于永久记忆。

Diagram 02 · Retrieval-Augmented Generation问题 → 检索 → Context → 回答 → 校验
用户问题
→
检索相关片段
→
片段进入 Context
→
模型基于证据生成
→
引用与事实校验
RAG 只能增加相关证据进入 Context 的机会，不能自动消除幻觉。权限过滤、来源引用和事实回读仍然必要。
04 / 三种形态

复杂，不等于 Agent。

一条固定流程即使有一百步，仍可能只是 Workflow。关键要看谁决定下一步，以及结果能否改变路线。

MODE / 01

LLM Chat

输入一次，生成一次。

  • 依赖本轮 Context
  • 不一定使用工具
  • 通常不维护任务状态
MODE / 02

Workflow

路线由人提前画好。

  • 固定步骤
  • 程序维护流程状态
  • 异常通常预先定义
MODE / 03

Agent

根据现场结果选择路线。

  • 目标驱动
  • Action–Observation
  • 可重试、询问和重规划
05 / 基础组成

五个零件，只有进入循环才成为 Agent。

LLM、Prompt、Memory、Knowledge 与 Tools 是基础组成；Runtime 才负责把它们组织成持续工作的系统。

01

LLM

理解任务、分析信息、判断下一步。

02

Prompt

职责、规则、限制、表达方式与成功标准。

03

Memory

保存进度、历史、经验与偏好，并按需召回。

04

Knowledge

通过 RAG 等方式提供外部事实与证据。

05

Tools

搜索、文档、日历、设备和业务系统等行动能力。

Diagram 03 · Model vs Runtime模型负责决策，Runtime 负责执行

Model

理解目标，选择工具并生成结构化参数。

ReasonPlanSelect

Agent Runtime

组织 Context，校验 Schema、权限与副作用，再调用真实工具。

ValidateAuthorizeExecuteRetry

External World

API、CLI、MCP Server 和设备改变真实系统，并返回 Observation。

APICLIMCPDevice
Function Calling 通常只是模型表达“想调用什么”；真实执行、确认、重试与回滚都属于 Runtime。
06 / Agent Loop

真正的分水岭，是行动之后还会观察。

连续工作不是模型永远醒着，而是 Runtime 一次次组织 Context、执行行动、接收 Observation 并再次调用模型。

Goal → Think → Act → Observe → Decide
STEP / 01

目标

Agent 不是围绕一句话生成内容，而是围绕一个尚未完成的目标维护任务状态。

映射到 Kriki“今天保持工作输出，同时不要继续累积疲劳。”这才是计划的目标，不是简单生成一条健康建议。
Diagram 04 · ReAct SequenceReasoning 与 Acting 交替进行
用户
查询北京明天的天气，并给出出行建议
收到天气结果和行动建议
Agent
判断：先查询天气
基于 Observation 整理建议
工具
小雨，12–18℃
真实查询完成
ReAct

做一步，看结果，再决定下一步。适合短任务和现场变化多的场景。

Plan-and-Execute

先形成整体计划，再逐步完成。适合目标明确的多步骤任务。

07 / 贯穿案例

智能会议助理，怎样从回答升级成 Agent。

同一个目标贯穿信息查找、内容处理、真实执行与安全确认，能把抽象框架落到具体工作现场。

01 定位会议先查日历，找到上一次产品评审会。
02 找到记录按会议时间检索文档、音频与图片。
03 处理输入必要时用 ASR / OCR 转换内容。
04 提炼结果提取决策、待办、负责人和截止时间。
05 真实回读创建文档后检查字段是否真实存在。
06 确认发送展示收件人与内容，用户确认后再发送。
08 / 映射 Kriki

Kriki Agent 的骨架，来自同一套运行原理。

健康模型和 Coach 人格很重要，但它们必须运行在可观察、可执行、可记忆、可纠正的系统里。

感知睡眠、恢复、负荷、主观状态与现实变化
上下文只组装当前决策需要的身体、目标和日程信息
推理理解原因，识别关键风险与机会
决策形成唯一主方案、替代方案和行动边界
执行更新计划、提醒、Watch 触点与下一次检查
记忆记录事实、模式、偏好和每次教练干预
学习根据执行与结果修正模型和协作方式
CHAPTER / 02

从一次回答，到持续运行的系统。

进阶篇关注工程实现：模型为何能连续工作，状态与记忆怎样管理，工具如何连接，以及如何证明任务真的完成。

进阶 · 选学
09 / 四层技术地图

不要把训练、模型与 Agent Runtime 混在一起。

训练改变模型参数；推理生成输出；Runtime 管理行动与状态；应用治理负责权限、评估、成本和体验。

训练层数据 → 预训练 → 指令微调 / 对齐 → 模型参数
模型层Token → Transformer 推理 → 结构化或自然语言输出
Agent 运行层Context Engineering → State / Memory / RAG → Tool Calling → Action / Observation
应用与治理层Workflow / Multi-Agent → 评估 → 可观测性 → 权限 → 成本
Diagram 05 · Action–Observation Runtime连续工作是 Runtime 重复组织输入与执行结果
Context
→
模型生成下一步
→
Agent Runtime
→
真实工具执行
→
Observation
→
更新 State
↺
重建 Context
模型并不会天然持续运行。每一轮都是一次新的模型调用，Runtime 负责把必要的历史、状态和工具结果重新组织进 messages / Context。
10 / Context Engineering

模型不是知道得越多越好，而是这一刻看到得刚刚好。

Context Window 是有限运行资源。选择、压缩、召回、隔离和工具结果过滤直接决定判断质量、延迟和成本。

State

当前任务走到哪里。

保存
目标、步骤、结果、错误、重试、预算
解决
不丢步、不重复执行
风险
状态错乱、并发冲突

Memory

过去发生过什么。

保存
事实、偏好、模式、经验、方法
解决
连续性和个性化
风险
错记、过期、隐私泄漏

RAG

现在需要哪些外部证据。

检索
文档、制度、产品知识与来源
解决
补充模型未知事实
风险
召回错误、越权、来源失真
Memory Types不是所有历史都该写入长期记忆
Working Memory当前任务的临时信息
Conversation对话历史与摘要
Episodic过去任务与执行经验
Semantic稳定事实与用户偏好
Procedural可复用的方法、流程与 Skill

Context Engineering 的常用动作

  • Sliding Window：只保留最近一段
  • Summarization：压缩长历史
  • Retrieval：按需召回知识与记忆
  • Structured State：结构化保存进度
  • Isolation：隔离用户、任务与 Agent
  • Priority / Truncation：按重要性裁剪
11 / RAG 与 Agentic RAG

检索也可以被规划，但自主性越高，越要控制停止条件。

普通 RAG 按预设链路检索；Agentic RAG 会拆解问题、改写查询、选择数据源、比较冲突，并判断是否继续。

Diagram 06 · Evidence Pipeline从查询表示到引用校验
当前问题
→
查询表示 / Embedding
→
关键词 / 向量 / 混合检索
→
重排与权限过滤
→
证据进入 Context 并回答
问题拆解
查询改写
数据源选择
判断证据是否充分或冲突
继续检索或停止
回答并引用验证
Agentic RAG 适合复杂、多跳、跨来源研究，但步骤增加也会扩大成本、延迟和错误面。应从普通 RAG 起步。
12 / 工具连接

模型决定调用什么，Runtime 才负责真的执行。

Function Calling 表达意图；API、CLI 和 MCP 提供不同连接方式；Schema、权限、确认、重试与副作用控制属于 Runtime。

Diagram 07 · Tool Connection连接协议不等于 Agent，也不等于工具本身
Model选择工具并生成结构化参数
→
RuntimeSchema · 权限 · 确认 · 执行 · 重试
本地函数
API / SDK
MCP Client → Server
受控 CLI
External World真实系统状态发生改变，并返回结构化 Observation
MCP 降低工具与资源的重复接入成本，但不负责模型推理、任务规划、身份授权或完整 Agent Loop。
Diagram 08 · Function Calling in Production从调用意图，到可信 Observation
LAYER / 01模型层

判断是否需要工具，选择工具并生成结构化参数。

→
LAYER / 02编排层 / Runtime

维护 Context 与 State，处理依赖、并发、超时、重试和停止。

→
LAYER / 03工具执行层

调用函数、API、数据库、CLI 或 MCP Server，处理真实副作用。

→
LAYER / 04结果回传层

关联调用 ID，规范化、截断与脱敏，再放回 Context。

结构校验JSON、类型、必填字段、枚举与 Schema。
业务校验日期、金额、资源状态、依赖与参数合法性。
安全校验身份、权限、数据范围、副作用与人工确认。
独立读取可以并行，需处理超时、取消和部分失败。
结果依赖B 依赖 A 时必须串行或按依赖图执行。
副作用动作发送、创建、发布、扣款需幂等与状态查询。
错误分类格式可修正；权限应停止；网络只有限重试。
对 Kriki：模型可以提出“重排训练计划”，但计划写入、提醒更新、权限确认和结果回读必须由 Runtime 负责；没有真实回读，就没有可信闭环。
13 / 更复杂的 Agent 形态

网页、世界模型与 Multi-Agent，都不是“越多越先进”。

优先选结构化、可校验的能力；只有任务能清晰拆分或确需不同权限与专业工具时，才值得拆成多个 Agent。

优先级 01

官方 API

结构化、稳定、容易校验，通常是 Web Agent 的首选。

优先级 02

DOM / 可访问性树

按网页结构操作，页面改版后可能失效。

优先级 03

视觉坐标 / Computer Use

最通用，但更易误点，高风险提交前必须回读。

世界模型

系统对“环境现在是什么状态、采取行动后可能发生什么”的内部表示。对软件 Agent，常体现为页面、文件、任务和工具状态。

Workspace Agent

长期存在于团队空间、持续承担某类岗位任务的产品形态。难点不只是回答，而是长期可靠、可追责地工作。

Supervisor–Worker

协调者拆分与汇总，多个执行者完成子任务。

S→WW
Planner–Executor

一个负责规划，一个负责执行。

P→E
Producer–Critic

一个生成，一个独立审查。

P↔C
Router–Specialists

根据问题路由给不同专业 Agent。

R→AB
14 / Agent Harness

不要相信 Agent 说“完成了”，要看真实世界有没有改变。

生产系统需要有限自主、真实回读、可观测性和评估。权限、预算、Trace、确认和恢复共同组成 Agent 的安全外骨骼。

最小权限读写分离，高风险操作先确认。
结构化校验Schema、白名单、业务规则与单元测试。
真实回读检查文件、页面、数据库和 API 的实际状态。
预算与停止最大步数、超时、重试、无进展检测与 Kill Switch。
完整 Trace记录 Context 来源、Action、Observation、错误、成本和确认点。
持续评估任务成功、工具准确、安全、可靠性、效率与成本。
定义任务边界、成功标准和不做什么。
能用普通程序或 Workflow 固定的步骤先固定。
把工具设计成结构化、单一职责、最小权限。
建立结构化 State 和 Context Builder。
实现 Action–Observation 循环与停止条件。
加入权限、确认、预算、超时、重试、幂等和回滚。
任务确实需要时，再加入 Memory、RAG 与 Multi-Agent。
建立 Trace、固定评估集和真实环境回读。

一分钟自测：哪个更像真正的 Agent？

请选择一个答案。

继续应用：Kriki Agent 用户侧与系统运行蓝图

原理之后，从用户画面与 Agent Trace 双视角查看晨间计划、动态重排、计划状态、工具执行和结果验证。

进入应用设计
原始学习材料 · 已同步 Revision 50

本页面根据《Agent 原理与框架：从入门理解到进阶系统》重新组织为团队学习体验，并把影响 Agent 设计的关键流程转换为响应式网页图解。

打开飞书原文