大模型与AI岗位速览 · 识汐 Wikitide

概览大模型术语、AI 应用形态和岗位方向，并梳理自研 Agent 的全栈架构与开发步骤。

先建立全局认知
大模型核心名词
AI 应用形态：不是固定等级，而是能力组合
岗位地图与求职判断
为什么要学习自研工程
自研 Agent 全栈架构
自研 Agent 全栈开发：16 个步骤
示范项目：企业知识研究 Agent
8–12 周学习与交付路线
作品集与面试表达
易错点总表
自测题与参考答案

1. 先建立全局认知

课件的主线可以压缩为一句话：

从“让模型回答”走向“让系统可靠地完成任务”，核心增量不是多调用几次模型，而是加入工具、状态、控制流、评测、安全与工程闭环。

1.1 三层能力地图

层次	解决的问题	典型技术	可交付结果
模型使用层	模型如何理解并生成内容	Prompt、结构化输出、上下文管理	稳定的单次模型调用
应用系统层	如何让模型接触知识并采取行动	RAG、Workflow、Agent、Tool Calling	可完成业务任务的应用
工程保障层	如何让应用长期可靠运行	评测、观测、权限、成本、部署	可上线、可审计、可迭代的系统

学习提示：岗位竞争力通常来自第三层。能做 Demo 说明“会用”，能用数据证明质量、成本和稳定性，才说明“会造”。

1.2 一条重要判断

Agent 是一种系统设计模式，不是一个单独模型。

一个 Agent 通常由模型、指令、工具、状态、控制循环和边界条件组成。规划、长期记忆、反思、多 Agent 都是可选能力，不是“只要叫 Agent 就必须拥有”的固定清单。

2. 大模型核心名词

2.1 Token

核心概念： Token 是模型编码与处理输入、输出的基本单位，也常是计费和上下文限制的计量单位。

Token 不一定对应一个汉字、一个词或一个字符。
数量取决于模型使用的 tokenizer、文本语言和内容形式。
“中文 1 字约等于 1–2 token”只能作为非常粗略的经验，精确预算必须用目标模型的 tokenizer 或 API usage 实测。

2.2 Embedding

Embedding（嵌入）是把文本、图片等对象映射为向量，使系统可以计算相似度。

常见用途：

语义检索：查询与文档块是否语义相近。
聚类与去重：发现内容簇或近重复文本。
推荐与匹配：用户、商品、知识条目的向量匹配。

易错点：向量相似不等于事实正确，也不等于业务相关。生产检索通常还需要关键词检索、元数据过滤、重排和评测。

2.3 Context

上下文窗口（Context Window）是单次请求可处理的信息容量；具体如何计算输入、输出和推理 token，要以目标模型文档为准。

上下文窗口不等于持久记忆。
能放进去不代表模型一定能准确利用。
长上下文会提高成本、延迟和“关键信息被淹没”的风险。

2.4 Hallucination

幻觉（Hallucination）指模型生成了缺乏依据、与事实冲突或无法由给定证据支持的内容。

常见诱因包括：问题含糊、上下文缺失、训练知识过时、检索错误、模型错误归纳，以及要求模型回答本就不可知的问题。

2.5 RAG

RAG（Retrieval-Augmented Generation，检索增强生成）先检索外部知识，再把检索结果作为上下文交给模型生成答案。

典型管线：

文档解析与清洗。
切块并补充元数据。
建立关键词和/或向量索引。
根据问题召回候选内容。
过滤或 rerank（重排）。
组织上下文并生成答案。
返回引用并记录评测数据。

限制：RAG 能提高事实依据和时效性，但不能“根治幻觉”。检索可能漏召回或召回错误，模型也可能误读证据。必须分别评测检索质量、答案忠实度和引用对应关系。

2.6 Fine-tuning

微调（Fine-tuning）使用任务或领域数据继续训练模型，以改变模型的行为、风格或任务表现。

名称	描述的维度	作用
SFT	训练信号/目标	用输入与示范输出进行监督训练
RLHF	对齐方法	利用人类偏好反馈优化模型行为
LoRA	参数更新方式	冻结主体权重，训练低秩增量参数

SFT、RLHF 与 LoRA 不是三个互斥的同层选项；LoRA 可以作为执行 SFT 等训练任务时的参数高效方法。

2.7 Prompt、RAG、微调如何选择

不要把“Prompt → RAG → 微调”理解为强制顺序。更可靠的决策方式是：

主要问题	优先手段
指令不清、输出格式不稳	改 Prompt、结构化输出、加入示例
缺少私有知识或最新知识	RAG 或工具查询
固定流程需要可靠执行	Workflow
步骤无法预先确定，需要动态用工具	Agent
风格、行为或专项任务表现不足	评估微调

Tip：永远先建立基线和评测集，再决定加组件。没有评测，复杂度只会增加，效果是否提高却无法证明。

3. AI 应用形态：不是固定等级，而是能力组合

课件使用“对话 → 工作流 → RAG → Agent → 数字员工”帮助理解应用能力，但这些概念处于不同维度，并非必须依次升级。

形态	控制权主要在谁	适合任务	优点	主要风险
对话	用户与模型	问答、草拟、辅助分析	简单、交互自然	输出不稳定，难形成闭环
Workflow	程序	步骤明确、规则稳定	可预测、易测试	难处理开放变化
RAG	检索系统 + 模型	私有知识问答、研究	知识可更新、可引用	检索与忠实度仍会失败
Agent	模型与程序共同控制	步骤不确定、需多工具	灵活处理复杂任务	成本、循环、越权风险
数字员工	业务系统整体	跨系统端到端流程	形成业务闭环	权限、审计、责任边界复杂

3.1 最实用的选择规则

能用普通代码解决，就先用普通代码。
步骤固定时，用 Workflow。
只是缺知识时，加 RAG。
只有当步骤或工具选择无法提前写死时，才让 Agent 动态决策。
高风险动作必须加确定性校验和人工审批。

自主性应只放在真正需要判断的环节，其他环节尽量保持确定性。

4. 岗位地图与求职判断

4.1 三类岗位

岗位方向	主要产出	核心能力	推荐作品
AI 应用工程	把模型做成可用产品	Python、API、Prompt、RAG、后端/前端、业务理解	可上线的 RAG 应用
Agent 工程	构建自主执行系统	工具设计、状态机、Agent 编排、评测、系统设计	有工具、审批、追踪和评测的 Agent
算法工程/研究	训练和优化模型	数学、Transformer、PyTorch、训练与推理优化	训练实验、论文复现、模型优化

现实 JD 会交叉：Agent 工程师通常也是应用工程师，还需要传统后端、数据库、云平台与运维能力。

5. 为什么要学习自研工程

“自研”不等于从零训练基础模型，也不等于拒绝云服务或开源框架。这里的含义是：关键业务逻辑、数据边界、评测方法和运行控制权掌握在自己手里。

维度	只堆平台的风险	自研工程要掌握的能力
控制	核心链路黑盒	明确状态、控制流和失败策略
定制	只能用通用能力	根据业务设计工具和数据模型
成本	按量调用失控	缓存、路由、预算与容量规划
数据	数据边界不透明	分类、脱敏、权限与私有部署选项
质量	只能凭主观体验	建立数据集、指标和回归测试
迁移	供应商锁定	抽象模型网关和工具协议

务实原则：框架和平台可以显著加速 0→1；学习目标不是重复造所有轮子，而是能解释并控制关键链路，且在框架不满足需求时有替换能力。

6. 自研 Agent 全栈架构

6.1 参考架构

flowchart TB
    U[Web / App 用户界面] --> API[API 网关与鉴权]
    API --> O[Agent Orchestrator 编排器]
    O --> M[模型网关]
    O --> T[工具注册表与执行器]
    O --> S[状态 / Checkpoint]
    O --> R[RAG 检索服务]
    T --> B[业务系统 / 数据库 / 第三方 API]
    R --> V[向量索引 + 关键词索引]
    O --> H[人工审批 Human-in-the-loop]
    O --> OBS[日志 / Trace / 指标 / 成本]
    E[离线评测与回归集] --> O
    OBS --> E

6.2 一次任务的生命周期

sequenceDiagram
    participant User as 用户
    participant API as API
    participant Agent as Agent 编排器
    participant LLM as 模型
    participant Tool as 工具
    participant Store as 状态存储

    User->>API: 提交目标
    API->>Agent: 创建 run
    Agent->>Store: 保存初始状态
    Agent->>LLM: 目标 + 状态 + 可用工具
    LLM-->>Agent: 结构化决策/工具调用
    Agent->>Tool: 参数校验后执行
    Tool-->>Agent: 结构化结果
    Agent->>Store: 写入事件与 checkpoint
    Agent->>LLM: 继续或总结
    LLM-->>Agent: 最终答案
    Agent-->>API: 结果 + 引用 + 运行摘要
    API-->>User: 流式展示

6.3 建议的项目目录

agent-app/
├── apps/
│   ├── api/                 # HTTP/SSE/WebSocket 接口
│   ├── worker/              # 异步任务、定时任务
│   └── web/                 # 前端界面
├── agent/
│   ├── orchestrator.py      # Agent 主循环
│   ├── planner.py           # 规划/路由（可选）
│   ├── policies.py          # 步数、预算、权限、审批策略
│   └── prompts/             # 版本化提示词
├── tools/
│   ├── registry.py          # 工具注册表
│   ├── contracts.py         # 输入输出 Schema
│   └── implementations/     # 工具实现
├── rag/
│   ├── ingest.py            # 解析、清洗、切块
│   ├── retrieve.py          # 召回
│   └── rerank.py            # 重排
├── domain/                  # 任务、Run、事件等领域模型
├── storage/                 # DB、对象存储、向量索引适配器
├── observability/           # 日志、Trace、指标、成本
├── evals/                   # 数据集、评分器、回归报告
├── tests/                   # 单元、集成、端到端测试
├── deploy/                  # 容器与部署配置
└── README.md

7. 自研 Agent 全栈开发：16 个步骤

下面的每一步都包含目标、要做什么与验收标准。建议按顺序完成，先做纵向最小闭环，再逐步增强。

步骤 1：定义问题与成功标准

目标：确认任务真的需要 Agent，并把“好用”转成可测试指标。

需要写清：

用户是谁，触发场景是什么。
输入、期望输出和禁止输出。
可调用哪些数据和系统。
哪些动作可自动执行，哪些必须人工审批。
可接受的延迟、成本、失败率与数据边界。

至少建立以下指标：任务成功率、正确性/忠实度、工具调用成功率、P95 延迟、单任务成本、人工接管率和高风险误操作数。

验收：准备 20–50 条代表性任务及期望结果，作为第一版黄金测试集。

步骤 2：先做非 Agent 基线

目标：知道 Agent 是否真的带来增益。

依次尝试：单次 Prompt → 带 RAG 的单次调用 → 固定 Workflow。只有当工具或步骤选择无法提前写死时，再进入动态 Agent。

验收：保存基线成功率、延迟与成本，后续每次改动都与它比较。

步骤 3：设计领域模型与状态

建议至少定义：

Task：用户目标与约束。
Run：一次任务执行实例。
Step：一次模型决策或工具动作。
ToolCall：工具名、参数、结果、错误与耗时。
Artifact：报告、文件、引用等产物。
Checkpoint：可恢复的状态快照。
Approval：高风险动作的审批记录。

状态不要只保存聊天文本；应保存结构化事实，例如 goal、plan、completed_steps、pending_approvals、budget_remaining 和 artifacts。

验收：任意一次失败运行都能回答“进行到哪一步、用了什么输入、为何失败、能否从哪里恢复”。

步骤 4：实现模型网关

目标：隔离供应商差异，让模型可替换、可降级、可计量。

模型网关应统一处理：

模型选择与路由。
Prompt 模板和版本号。
结构化输出 Schema 校验。
超时、有限重试和退避。
token、成本、延迟统计。
内容安全与敏感信息处理。
降级策略，例如强模型失败后切备用模型。

警告：不要对非幂等请求无限重试，也不要在模型输出解析失败后“悄悄猜值”。解析失败应成为可观测事件。

验收：替换模型时，业务层无需改动；每次调用都能追踪 prompt 版本、耗时和用量。

步骤 5：设计工具契约

工具（Tool）是 Agent 对外部世界采取行动的最小能力单元。

每个工具都应包含：

单一、清晰的职责。
明确的 JSON 输入/输出 Schema。
参数范围、枚举、默认值和示例。
身份与权限上下文。
超时、限流、重试和错误码。
幂等键或去重机制。
审计字段与结果摘要。

class ToolResult(BaseModel):
    ok: bool
    data: dict | None = None
    error_code: str | None = None
    error_message: str | None = None
    retryable: bool = False

async def create_ticket(args: CreateTicketArgs, ctx: ToolContext) -> ToolResult:
    authorize(ctx.user, action="ticket:create")
    validate_business_rules(args)
    return await ticket_service.create(args, idempotency_key=ctx.call_id)

验收：工具可以脱离模型单独做单元测试；非法参数被拒绝；重复请求不会重复产生副作用。

步骤 6：实现最小 Agent 循环

核心循环不是神秘的“思考”，而是一个有边界的状态机：

async def run_agent(state):
    while not state.done:
        enforce_limits(state)  # 步数、时间、token、费用
        decision = await model.decide(
            goal=state.goal,
            state=state.public_view(),
            tools=tool_registry.schemas(),
        )

        if decision.type == "final":
            state.finish(decision.answer)
            break

        call = validate_tool_call(decision.tool_call)
        if requires_approval(call):
            state.pause_for_approval(call)
            break

        result = await tool_executor.execute(call)
        state.record(call, result)
        await checkpoint_store.save(state)

    return state

必须有终止条件：最大步数、最大运行时间、最大费用、连续失败次数、重复调用检测和用户取消。

验收：在工具连续失败、模型重复调用或返回非法参数时，Agent 能安全终止并给出可解释错误。

步骤 7：规划、路由与控制流

不要一开始就做复杂规划。可按复杂度逐级增加：

单 Agent 直接选择工具。
先分类再路由到固定 Workflow。
为长任务生成简短计划，并逐步校验。
只有任务天然需要角色隔离时才考虑多 Agent。

计划应包含步骤、依赖、完成条件与可用工具，而不是只有宽泛自然语言。

验收：对同一组测试任务，规划机制应显著提高成功率，而不是只增加 token 和延迟。

步骤 8：加入状态、记忆与上下文管理

记忆类型	保存内容	推荐位置
工作记忆	当前任务步骤、工具结果	Run state / checkpoint
会话记忆	本次会话的关键事实	数据库中的结构化摘要
语义记忆	文档与知识	RAG 索引
用户偏好	经授权保存的稳定偏好	用户资料库
事件记忆	历史任务及结果	审计/事件表

记忆写入必须有规则：什么值得保存、保存多久、谁可以读取、用户如何查看和删除。不要把全部对话无差别塞回上下文。

验收：任务可中断恢复；上下文增长可控；过期、敏感或错误记忆能被删除或纠正。

步骤 9：接入可评测的 RAG

RAG 要分开评测两个阶段：

检索阶段：Recall@K、MRR/nDCG、命中文档比例、过滤准确率。
生成阶段：答案正确性、忠实度、引用完整性、拒答质量。

实作建议：

按内容结构切块，保留标题、页码、时间、权限等元数据。
采用关键词 + 向量的混合召回。
对候选结果做 rerank。
上下文去重并控制 token 预算。
要求关键结论带引用；证据不足时允许拒答。
对文档更新、删除和权限变更建立同步机制。

验收：准备带“期望证据”的查询集，能区分是没检索到、检索错了，还是模型没有忠实使用证据。

步骤 10：加入 Checkpoint、恢复与人工审批

对长任务，每个副作用动作前后都保存 checkpoint。高风险动作采用“提议 → 展示影响 → 人工批准 → 执行 → 审计”的流程。

典型需审批动作：发消息、支付、删除、对外发布、修改生产数据、授予权限。

验收：服务重启后能从最近安全点恢复；未审批动作绝不会执行；审批记录能关联用户、时间、参数和结果。

步骤 11：建立安全与权限边界

至少覆盖：

最小权限和租户隔离。
Secret 不进入 Prompt、日志或前端。
工具参数服务端再次校验，不能只相信模型。
把外部网页、邮件、文档视为不可信输入，防范 Prompt Injection。
读工具与写工具分离；高风险写操作使用 allowlist。
PII 脱敏、保留期和删除机制。
输出内容审核与审计追踪。

关键原则：模型只能“建议调用工具”，是否允许执行必须由确定性的权限与策略代码决定。

验收：使用越权、恶意文档、Prompt Injection、参数篡改和重复提交测试，系统应拒绝或转人工。

步骤 12：做好可观测性

一次 run 应形成完整 Trace：

run_id
├── model_call: prompt_version, model, tokens, latency, cost
├── tool_call: name, validated_args, result_code, latency
├── retrieval: query, filters, document_ids, scores
├── approval: actor, decision, timestamp
└── final: status, answer, citations, quality_flags

推荐监控：成功率、P50/P95 延迟、每任务 token/成本、工具失败率、重试率、人工接管率、循环终止率、检索空结果率。

验收：收到一个失败 run_id 后，能在几分钟内定位失败组件和输入输出，不需要靠复现猜测。

步骤 13：建立评测与回归体系

评测集应包含：正常任务、边界条件、工具失败、信息不足、恶意输入和高风险动作。

指标	含义
Task Success	最终是否完成用户目标
Tool Selection	是否选择正确工具
Argument Validity	参数是否符合 Schema 与业务规则
Groundedness	结论是否由证据支持
Safety	是否越权或执行不安全动作
Efficiency	步数、延迟与成本是否合理

评分方式可组合：确定性断言、规则评分、人工抽检、模型评审。模型评审不能作为唯一裁判，关键结果应有可重复的程序化断言。

验收：每次改模型、Prompt、工具或检索策略都自动跑回归；质量下降超过阈值时阻止发布。

步骤 14：建设后端 API 与异步执行

推荐端点：

POST   /runs                 创建任务
GET    /runs/{id}            查询状态
GET    /runs/{id}/events     SSE 流式事件
POST   /runs/{id}/cancel     取消任务
POST   /runs/{id}/approve    审批动作
GET    /runs/{id}/artifacts  获取产物
POST   /feedback             提交反馈

短任务可在 API 内完成；长任务应交给 worker/queue。接口要支持幂等、取消、超时、重连和背压。

验收：刷新页面或客户端断线不会丢任务；SSE 重连能从事件序号继续；并发请求不会串状态。

步骤 15：建设可理解、可控制的前端

前端不应只显示“正在思考”，而应展示用户真正需要的运行状态：

当前阶段和已完成步骤。
正在调用的工具及安全摘要。
引用来源与生成产物。
等待审批的动作及影响范围。
取消、重试、修改参数和接管入口。
成功/失败的明确收尾状态。

不要展示模型隐藏推理；应展示由系统生成的可审计事件摘要。

验收：用户能判断系统是否仍在运行、为何等待、下一步会发生什么，以及如何停止。

步骤 16：容器化、部署与持续迭代

部署前检查：

API、worker、数据库、缓存、对象存储和索引的容量。
Secret 管理、网络边界、备份和灾难恢复。
健康检查、灰度发布、回滚与版本关联。
模型/Prompt/工具/知识库版本可追踪。
预算上限、速率限制和异常告警。

上线后的闭环：生产反馈 → 失败分类 → 补充评测样本 → 修改 → 回归 → 灰度 → 监控。

验收：能一键部署测试环境；能回滚上一版本；版本变化能映射到质量、延迟和成本变化。

8. 示范项目：企业知识研究 Agent

8.1 项目目标

用户输入一个研究问题，Agent 自动检索内部资料，必要时调用外部查询工具，生成带引用的报告；涉及外部发布时必须人工审批。

8.2 最小可用范围

上传 PDF/Markdown 并建立索引。
使用混合检索和 rerank。
Agent 可调用 search_knowledge、fetch_document、calculate、create_report。
报告中的关键结论附文档与页码引用。
页面展示运行步骤、引用和产物。
保存 Trace、token、成本与反馈。

8.3 分阶段实现

里程碑	功能	验收
M1	单文档问答	20 条问题有可核对引用
M2	多文档 RAG	召回与答案分别有指标
M3	工具 Agent	能在 3–5 个工具间正确选择
M4	长任务与恢复	中断后从 checkpoint 继续
M5	审批与安全	写操作未经批准不执行
M6	全栈上线	在线 Demo、监控、评测报告齐全

8.4 示例验收用例

case: compare_two_policies
input: "比较 A、B 两份制度的报销上限，并注明依据。"
expected:
  required_tools: [search_knowledge, fetch_document]
  must_cite: true
  forbidden_actions: [send_email, update_database]
  assertions:
    - mentions_both_policies
    - every_limit_has_citation
    - no_unsupported_number

8.5 README 应展示的证据

架构图与关键设计取舍。
30–100 条评测集及结果。
与非 Agent 基线的对比。
成功/失败 Trace 截图。
安全边界与审批流程。
P95 延迟、平均成本、任务成功率。
本地运行、测试和部署命令。

9. 8–12 周学习与交付路线

阶段一：打地基（第 1–2 周）

Python：类型、异步、异常、测试、包管理。
HTTP/API：鉴权、超时、重试、SSE。
数据库：SQL、事务、索引。
大模型 API：结构化输出、工具调用、token 与成本。

交付物：一个带结构化输出、测试和日志的模型 API 服务。

阶段二：RAG 与基线（第 3–4 周）

文档解析、切块、索引、混合召回、rerank。
建立问题集，分别评测检索和生成。
做固定 Workflow 作为 Agent 基线。

交付物：可引用、可评测的 RAG 服务和基线报告。

阶段三：Agent 核心（第 5–7 周）

工具契约、注册表、执行器。
有边界的 Agent 循环。
结构化状态、checkpoint、失败恢复。
权限检查与人工审批。

交付物：能完成多步任务且可安全终止的 Agent。

阶段四：全栈与工程化（第 8–10 周）

API + worker + SSE。
前端运行时间线、引用、审批和取消。
Trace、指标、成本和告警。
离线评测与 CI 回归。

交付物：完整线上 Demo、评测报告和监控面板。

阶段五：打磨作品集（第 11–12 周）

增加失败案例和对抗测试。
优化成功率、延迟与成本。
完善 README、架构决策记录和演示视频。
对照 20–30 份目标 JD 调整项目描述。

交付物：仓库、Demo、演示视频、项目复盘与简历要点。

10. 作品集与面试表达

10.1 不要只说“使用了什么”

弱表达：

使用 LangChain、向量数据库和大模型搭建 Agent。

强表达：

为企业制度研究任务设计 6 个受控工具和可恢复状态机；在 80 条回归集上，任务成功率从固定 Prompt 基线的 61% 提升到 84%，P95 延迟 18 秒，平均单任务成本 0.12 元；写操作采用服务端权限校验和人工审批，所有步骤可通过 run_id 追踪。

10.2 面试讲解顺序

业务问题和为何需要 Agent。
基线方案及其失败点。
架构与最关键的设计取舍。
工具、状态、RAG、权限如何实现。
如何评测，指标提高了多少。
失败案例、成本和下一步改进。

11. 易错点总表

易错理解	更准确的认识
长上下文就是长期记忆	长上下文是单次容量；持久记忆需外部存储和写入策略
RAG 能根治幻觉	RAG 提供依据，但检索和生成仍会出错
向量数据库是 RAG 的必需品	RAG 可用关键词、语义或混合检索
对话→工作流→RAG→Agent 是固定升级路线	它们是可组合能力，按任务选择
Agent 必须有规划、记忆、反思	这些是按需加入的设计能力
多 Agent 一定更强	多 Agent 增加协调、成本和故障面，只在角色隔离确有价值时使用
模型决定调用工具就可以直接执行	最终授权必须由确定性策略和服务端校验完成
Demo 能跑就代表可上线	还需要评测、观测、恢复、安全、成本和部署
微调能补充最新私有知识	新知识通常优先用 RAG/工具；微调更适合行为和任务表现
自研等于不用框架、不用云	自研是掌握关键链路和控制权，可合理使用平台加速

12. 自测题与参考答案

12.1 自测题

为什么上下文窗口不等于记忆？
RAG 的检索质量与生成质量应分别用哪些指标观察？
什么情况下 Workflow 比 Agent 更合适？
一个生产工具契约至少要包含哪些内容？
为什么 Agent 主循环必须设置步数、时间和费用上限？
如何防止模型被恶意文档诱导执行越权动作？
为什么要先建立非 Agent 基线？
前端为什么不应只显示“正在思考”？
如何证明项目具备工程价值，而不仅是 Demo？
SFT、RLHF、LoRA 为什么不是三个同层替代选项？

12.2 参考答案

上下文只存在于单次请求；跨任务记忆需要外部存储、检索、权限和生命周期管理。
检索可看 Recall@K、MRR/nDCG；生成可看正确性、忠实度、引用完整性与拒答质量。
当步骤、分支和规则可以提前确定，且需要高可预测性时优先 Workflow。
输入输出 Schema、权限、超时、限流、错误语义、幂等、审计和示例。
防止无限循环、成本失控、服务阻塞和重复副作用。
把外部内容视为不可信数据；模型只提议动作；服务端独立做权限、参数和策略校验，高风险动作加审批。
用于证明 Agent 是否真正提高成功率，并量化其额外延迟和成本。
用户需要知道当前阶段、等待原因、后续影响，以及如何取消、审批或接管。
提供可复现评测、成功率、延迟、成本、失败分析、安全边界、监控和部署证据。
SFT/RLHF主要描述训练信号和目标，LoRA 描述参数高效更新方式，它们可以组合使用。

参考与核验说明

课件技术框架：第 4–10、14、16–18 页。
自研 Agent 全栈步骤：依据课件第 17–18 页“RAG 管线—Agent 编排—模型工程化”与“打地基—做深—作品集”的方向做工程化扩展。
Token 与上下文修订：OpenAI - Understanding tokens。
RAG 限制与评测意识：Microsoft - Retrieval-Augmented Generation。
Workflow 与 Agent 的区分：Anthropic - Building effective agents。
RLHF 基本流程：InstructGPT 论文。
LoRA 原始研究：LoRA: Low-Rank Adaptation of Large Language Models。

岗位与薪资数字来自课件，部分只能找到媒体转述或二手文章，统计时期、样本、去重与薪酬口径未完整核实。本笔记不把这些数字用作个人求职概率或薪酬承诺。