这是《AI Agent 工程进阶从 Demo 到可靠系统》的第 1 篇。系列从一个看起来不够“AI”的问题开始在接入模型、工具、Memory 或 Graph 之前这个系统到底替谁完成什么工作什么算完成什么不能做我们又凭什么判断它值得被做成 Agent很多 Agent 项目的第一条需求是提示词做一个能回答内部问题的 Agent。这句话能表达方向却不能直接指导工程实现。它没有说明“内部问题”来自谁哪些资料可以读取资料不足时能不能猜回答一段文字是否就算完成是否允许联网、写文件或发布结果什么时候必须拒答或交给人一个普通检索脚本已经能做到多少。如果这些问题没有答案后面再精巧的 Prompt、Tool、Loop 和 Graph 都只是在放大一个模糊目标。因此本篇不会先接模型。我会在公开仓库 RalfNick/ai-agent-learn 的真实代码上建立一个Agent Reliability Lab先交付四样东西提示词Agent System Card 可执行任务集 非 Agent 控制组 可检查的失败报告然后用三个实验回答合同写错时会发生什么拒答阈值过低和过高时会发生什么以及当前证据是否真的支持升级 Agent。项目说明内容类型AI Agent 工程教程与可复现实验适合读者已经能调用模型或运行 Agent希望把 Demo 变成可评估系统的开发者阅读时间速读约 10 分钟完整阅读约 14-20 分钟跟做时间45-60 分钟实验环境Python 3.10零第三方依赖不需要 API Key代码检查点556bace可带走产物Agent System Card、任务集、确定性基线、失败实验与检查清单资料核对日期2026-07-26术语边界本文的Agent System Card是我为这个系列整理的工程模板用于把产品、运行时、评测和运营约定放在同一份版本化文件里。它不是 OpenAI 官方字段不是模型厂商发布的 Model System Card也不是 A2A 协议中用于服务发现的Agent Card。卡片里的声明也不是安全机制。prohibited_actions写着“禁止联网”并不会自动切断网络真正的限制仍要由 Sandbox、权限、工具注册表、审批和运行时策略执行。下文用System Contract指这套系统约定用System Card指它在仓库中的结构化 JSON 载体。一分钟概览如果只保存这篇文章的结论可以记住下面七句Agent 需求的最小单位不是 Prompt而是一个可判断完成或失败的现实任务。系统契约连接产品、Runtime、Eval 与 Ops但不会替代其中任何一层。Done要描述可验证结果Failure要描述明确终态不能只写“尽量完成”。“允许”“禁止”和“需要批准”是三种不同策略不能互相矛盾。任务集中的 Grader 只能检查任务描述已经承诺的内容不能暗中增加要求。先运行脚本或固定工作流只有动态决策带来可测量净收益时才升级 Agent。当前 Lab 的5/5只说明一个小型控制组通过反而还没有证明必须使用 Agent。三种阅读方式只想理解概念读第 1-3、9-11 节。准备运行代码读第 4-8 节。想直接用于自己的项目读第 12-14 节并下载文末模板。图 1Agent 系统契约的责任边界图 1System Contract 是四类角色之间的共同接口。Contract 负责声明Runtime 负责强制Eval 负责验证Ops 与人负责审批、接管和追责。移动端可点击查看原图。为什么“做一个 Agent”不是可执行需求OpenAI 的 Agent 实践指南把 Agent 的基础组成概括为模型、工具与指令并建议优先选择传统规则难以覆盖、依赖非结构化信息或需要复杂判断的工作如果这些条件并不成立确定性方案可能已经足够。Anthropic 对 Workflow 与 Agent 的区分也很有帮助Workflow 由预先定义的代码路径编排模型和工具Agent 由模型动态决定过程与工具使用两者都应该从能解决问题的最简单结构开始。因此“是否使用 Agent”不是产品名称而是一个架构判断提示词任务是否需要在运行过程中根据不完整信息动态选择行动、工具或恢复路径下面这些工作不一定需要 Agent根据固定字段生成日报**更可能的起点**模板或脚本**原因**输入和输出结构稳定从一份手册检索对应段落**更可能的起点**搜索或确定性检索**原因**路径固定可直接验证对一批格式统一的文件做转换**更可能的起点**批处理 Workflow**原因**步骤已知不需要动态规划在多个工具间调查异常并根据结果改计划**更可能的起点**Agent**原因**下一步依赖中间观察跨系统处理例外并在风险动作前请求批准**更可能的起点**Agent Runtime Policy**原因**需要动态决策与人工边界如果一开始就默认“必须是 Agent”团队很容易把所有失败归因于模型或 Prompt却没有一个简单控制组回答这部分工作是不是原本就可以用更便宜、更稳定的程序完成系统契约位于哪一层OpenAI 的 Define agents 文档会要求开发者配置 Agent 的名称、指令、模型、工具、Handoff、结构化输出、Guardrail、Approval 和 MCP 能力。这些是运行实现的重要组成。本文再向前走一步在选择具体 SDK 和模型之前先建立一份供应商中立的系统约定。提示词产品目标 ↓Agent System Contract ├── Runtime / Harness怎样执行和限制 ├── Eval / Grader怎样判断和比较 └── Ops / Human怎样批准、接管和追踪它主要解决四类错位。产品与模型错位产品要的是“减少工程手册查询时间”模型输出的是“一段看起来合理的文字”。两者不是同一个完成条件。Prompt 与权限错位Prompt 说“不要联网”只是行为指令。网络是否真的不可用要由运行环境决定。Task 与 Grader 错位任务只要求“修复登录跳转”隐藏测试却要求一个没有在需求中出现的函数名。此时失败可能来自评测而不是实现。Demo 与生产错位一次成功演示没有描述超时、证据不足、工具失败、审批拒绝和人工接管。所以System Contract 的价值不在于文档更完整而在于让不同代码层共享同一个责任定义。Agent System Card 的八个部分本系列把卡片拆成八部分图 2Agent System Card 的八个组成部分图 2八个部分分别回答工作、输入、完成、边界、失败、证据、控制组和版本问题。字段是本文的教学模板不是行业标准。3.1 Job替谁完成什么现实工作代码{ job: { actor: 需要查询内部工程手册的开发者, task: 根据允许读取的知识库回答问题并在证据不足时明确拒答, why_agent: 后续版本需要在检索、工具、验证和人工审批之间做受约束的动态决策 }}actor防止需求退化为泛用聊天task指向现实工作why_agent则是一条待验证假设不是预先成立的结论。这里最关键的措辞是“后续版本需要”。当前控制组还没有证明它成立。3.2 Input输入和信任从哪里来代码{ input: { required: [question], trusted_sources: [fixtures/knowledge/*.md], untrusted_sources: [user_question] }}把用户问题标记为untrusted不是说用户一定恶意而是提醒 Runtime问题内容不能修改系统规则问题中出现的路径或命令不能自动获得权限用户声称的内部事实不能替代受控资料。同样trusted_sources也只是合同中的允许列表。文件是否真实、是否过期、是否被篡改还需要来源校验、版本和访问控制。3.3 Done什么状态才算完成代码{ done: { terminal_states: [answered, abstained], validators: [ 回答包含任务要求的关键事实, 回答只使用允许的资料, 资料不足时状态必须为 abstained ] }}abstained被放进合法终态是因为对知识库系统来说没有证据时明确拒答可能比生成一段流畅文字更接近完成。这与failed不同。拒答是系统按设计工作失败则可能是文件不可读、解析错误、超时或预算耗尽。3.4 Boundary允许、禁止和需审批代码{ boundaries: { allowed_actions: [read_knowledge, return_answer, abstain], prohibited_actions: [write_source, use_external_web], approval_required: [change_policy, publish_result] }}三组动作必须语义一致提示词allowed 当前策略下可以执行prohibited 当前系统无论如何都不能执行approval 暂停运行得到授权后才可执行早期版本曾把publish_result同时放进“禁止”和“需要批准”。这会让 Runtime 无法回答批准之后到底能不能发布契约校验器现在会拒绝这种冲突。但仍要注意校验器只能检查声明是否自洽真正执行publish_result的工具仍需要身份、权限和 Approval。OpenAI 的 Guardrails 与 Approvals 文档特别强调检查位置涉及副作用的验证应该靠近产生副作用的工具。不能只在最终输出端检查一句“我没有发布”。3.5 Failure失败怎样结束和移交代码{ failure: { terminal_states: [failed, handed_off], handoff_when: [ 资料互相冲突, 任务请求越过允许的数据边界, 预算或重试次数耗尽 ] }}一个系统如果只有success失败时就容易变成提示词继续试 → 换一种说法再试 → 忽略风险继续试 → 最后把不确定结果包装成完成明确failed和handed_off后Runtime 才能设计超时、重试上限、暂停状态和人工接管。3.6 Evidence用什么证据判断版本代码{ evidence: { dataset: datasets/tasks.jsonl, primary_metrics: [ task_pass_rate, correct_abstention_rate ], secondary_metrics: [ retrieved_chunk_count, latency_ms ] }}这部分不要求第一天就有完整评测平台但至少要把“以后凭什么判断”写出来。没有 Evidence 时系统改动通常会被描述成提示词新版回答更自然。新版看起来更聪明。新版用了更强模型。这些都不是可回归的结论。3.7 Baseline不用 Agent 能做到什么代码{ baseline: { strategy: deterministic_paragraph_retrieval, command: python run_lab.py baseline, agent_required_if: 动态工具选择或跨步骤恢复在同一任务集上带来可测量收益 }}agent_required_if是整张卡片里最值得保留的一行。它把“我们想做 Agent”改成了一个可以被证伪的判断如果确定性检索已经稳定完成任务后续 Agent 必须在更复杂的任务上证明收益而不是只增加 Token、延迟和故障面。3.8 Version让约定变化可追踪当前卡片有独立的id和version代码也固定到 Git commit。版本化至少要回答任务定义何时改变哪些边界被放宽或收紧Grader 是否增加了条件哪个 Runtime 版本执行了这份合同历史分数是否仍然可以比较。如果任务和 Grader 已经变了却继续沿用同一个“成功率”指标就失去了含义。进入真实工程Agent Reliability Lab本篇代码位于phase-7-agent-engineering/agent-reliability-lab它建立在仓库 Phase 6 的企业知识库 Agent 之上但第一篇刻意把模型调用拿掉只保留任务与控制组。这不是重新写一个无关 Demo而是先从既有系统中提取责任和证据workflow.py中的检索、证据检查、修复与拒答节点**本篇怎样接住**提炼为Job、Done、Failure和允许动作**暂时没有伪装成已完成的部分**暂未把 Card 自动转换成 Runtime Policyevaluator.py中的状态、关键词、来源与 Trace 检查**本篇怎样接住**收缩成五条可重复任务和最小 Grader**暂时没有伪装成已完成的部分**暂未加入重复 Trial、模型评分和人工复核Phase 6 的 Agentic QA 工作图与 Trace**本篇怎样接住**保留为后续版本要比较的候选系统**暂时没有伪装成已完成的部分**本篇不声称 Agent 已经优于控制组提示词agent-reliability-lab/├── contracts/│ └── agent-system-card.json├── datasets/│ └── tasks.jsonl├── fixtures/knowledge/│ └── product-handbook.md├── agent_lab/│ ├── contracts.py│ ├── baseline.py│ └── reporting.py├── examples/│ └── invalid-card.json├── reports/│ ├── baseline.json│ ├── baseline.md│ └── local/ # 本地生成Git 忽略├── tests/└── run_lab.py图 3Agent Reliability Lab 的代码与证据流图 3合同、任务和允许资料分别进入校验器与控制组输出结构化报告。底部三个失败实验用于证明校验和阈值确实会改变行为。4.1 获取固定版本命令git clone --branch agent-engineering-series https://github.com/RalfNick/ai-agent-learn.gitcd ai-agent-learngit checkout 556bacecd phase-7-agent-engineering/agent-reliability-lab如果你已经在仓库根目录命令cd phase-7-agent-engineering/agent-reliability-lab实验只使用 Python 标准库。先运行三条命令命令python run_lab.py check-contractpython run_lab.py baselinepython -m unittest discover -s tests -v把三次输出合起来应该能核对到提示词contract status: validtasks: 5passed: 5task_pass_rate: 1.0correct_abstention_rate: 1.0tests: 9 passed不同机器的latency_ms会变化不应该拿来逐字比较。默认命令把本地结果写入reports/local/该目录被 Git 忽略仓库根部的reports/baseline.json和reports/baseline.md是随代码检查点提交的参考报告。这样读者运行实验不会因为机器延迟不同而得到一份无意义的 Git diff。契约校验器到底检查什么agent_lab/contracts.py的第一层检查是完整性代码REQUIRED_SECTIONS { id, version, job, input, done, boundaries, failure, evidence, baseline,}第二层检查id、version、对象结构、必填字段和空值并要求几组策略数组由非空字符串组成且没有重复项。第三层再检查语义冲突代码_reject_overlap( allowed_actions, prohibited_actions, actions cannot be both allowed and prohibited,)_reject_overlap( prohibited_actions, approval_required, actions cannot be both prohibited and approval-gated,)_reject_overlap( success_states, failure_states, terminal states cannot be both successful and failed,)现在运行坏契约命令python run_lab.py check-contract --contract examples/invalid-card.json预期退出码是1输出为代码{ status: invalid, path: examples\\invalid-card.json, error: actions cannot be both allowed and prohibited: read_knowledge}这说明结构化契约比一段散落在文档里的描述更容易进入 CI。但校验器不能证明fixtures/knowledge/*.md真的可信运行时真的断开了外网工具不会绕过prohibited_actions回答符合真实业务Grader 没有遗漏重要风险。当前run_lab.py也没有根据卡片自动配置权限或推导文件路径它先验证 Contract再读取 CLI 指定的--tasks与--knowledge。这是0.1.0有意保留的实现边界后续 Harness 才会把声明映射为真正的运行策略。所以正确关系是提示词Contract Validator检查约定是否完整、自洽Runtime Policy强制权限、工具和状态边界Eval检查行为和现实结果Human / Ops处理高风险判断与责任不要把“配置文件通过校验”误写成“系统已经安全”。把需求写成可执行任务当前datasets/tasks.jsonl有五条任务代码{id:qa-001,question:工具服务持续限流时系统应该怎样降级,expected_status:answered,expected_terms:[只读模式,人工处理]}{id:qa-005,question:公司差旅报销的每日额度是多少,expected_status:abstained,expected_terms:[]}一条最小任务包含id**作用**稳定追踪失败样本**是否给被测系统**可以question**作用**系统实际收到的输入**是否给被测系统**是expected_status**作用**Grader 判断回答或拒答**是否给被测系统**否expected_terms**作用**最小事实检查**是否给被测系统**否控制组只使用question检索资料expected_status和expected_terms只在结果产生后评分。当前 Grader 对关键词使用的是最简单的包含判断代码for term in task.expected_terms: if term not in answer: failures.append(fmissing_term:{term})这只适合作为 Smoke Test。例如下面这句包含“最小权限、脱敏、审计”三个词却明显是错误答案提示词系统不需要最小权限也不用脱敏只要保留审计即可。它仍可能通过关键词检查。因此本篇的passed只能表示“状态与最小词项条件通过”不能代表语义和业务事实已经完整正确。第 2 篇会加入更强的确定性检查、重复 Trial、必要的模型评分和人工抽查。6.1 为什么一定要有拒答任务如果任务集只有“资料中存在答案”的问题一个最差策略也可能得高分提示词无论证据多少都生成答案。加入未知的差旅额度问题才能观察系统是否会在没有证据时停下来。更完整的任务集还需要可回答与不可回答正常输入与边界输入单一证据与冲突证据只读任务与需审批动作能力任务与回归任务。Anthropic 在 Demystifying evals for AI agents 中建议早期可以从真实失败中收集约20-50个简单任务并明确区分 Task、Trial、Grader 和 Transcript。因此本篇的5条任务只是教学控制组不是生产规模 Eval。第 2 篇会扩充任务、加入重复 Trial 和更完整的 Grader。6.2 Grader 不能暗中改变合同SWE-bench 提供了一个很值得借鉴的任务结构提示词代码仓库 Issue 描述 → 生成 Patch → fail-to-pass 与 regression tests 判断结果它把环境、任务、执行和评测分开是很好的工程思想。但评测本身也可能出错。OpenAI 在 2026 年 2 月发布的 SWE-bench Verified 审计 中指出部分问题的测试会要求任务描述没有说明的行为或者过度限定实现细节环境差异也可能造成伪失败。OpenAI 因此不再用 SWE-bench Verified 衡量前沿模型进展。这给普通 Agent 项目的提醒是Grader 检查的每个关键条件都应该能回到任务描述、业务规则或明确的安全策略。隐藏答案可以隐藏需求不行。为什么控制组故意不用模型agent_lab/baseline.py实现了一个很朴素的段落检索器把中文连续文本切成 bigram提取英文和数字词项计算问题词项与每个段落的重合率低于阈值时拒答否则直接返回得分最高的段落。核心评分只有代码overlap query_tokens chunk_tokensscore len(overlap) / len(query_tokens)拒答逻辑是代码if best_chunk is None or best_score threshold: status abstained answer 根据当前允许读取的资料我无法可靠回答这个问题。else: status answered answer _content_without_heading(best_chunk)它显然不是一个强检索系统不理解同义词和语义对问题措辞敏感不能合并多个段落不能处理冲突资料不能选择外部工具不能根据中间结果恢复步骤。这些限制不是缺陷清单而是控制组的意义。它便宜、确定、容易解释后续复杂版本必须在同一任务上证明自己解决了哪些限制。图 4从非 Agent 基线到 Agent 的升级门槛图 4真实任务先进入确定性基线。只有动态决策在相同任务、边界和预算下产生可测量收益才进入 Agent 候选版本。三个实验让失败成为可见证据只展示5/5很容易让教程看起来正确却不能证明系统的边界真的存在。所以 Lab 提供三个故意失败的实验。实验 A边界自相矛盾命令python run_lab.py check-contract --contract examples/invalid-card.json坏卡片同时允许和禁止read_knowledge。命令返回结构化错误并以状态码1结束。它验证的是合同的语义一致性不是运行时权限。实验 B阈值过低系统过度回答命令python run_lab.py baseline --threshold 0.0 --output reports/threshold-zero结果提示词task_pass_rate: 0.8correct_abstention_rate: 0.0qa-005: answered ! abstained差旅问题与任何资料都没有词项重合但阈值为0时系统仍然允许返回一个段落。它把“不知道”伪装成了回答。实验 C阈值过高系统过度拒答命令python run_lab.py baseline --threshold 1.0 --output reports/threshold-one结果提示词task_pass_rate: 0.2correct_abstention_rate: 1.0qa-001..qa-004: abstained ! answered系统成功避开了未知问题却把四个能够回答的问题也拒绝了。8.1 为什么两个指标都要看如果只看correct_abstention_rate阈值1.0看起来非常安全如果只看“回答数量”阈值0.0看起来覆盖率最高。真实系统需要同时处理两类错误提示词False Answer 没有证据却回答False Abstention 有足够证据却拒答这也是为什么 System Contract 不能只写“避免幻觉”。“一律不回答”确实很少幻觉但也没有完成工作。5/5到底证明了什么默认阈值0.28的结果是qa-001限流降级**Score**0.60**Status**answered**Passed**yesqa-002发布门禁**Score**0.46**Status**answered**Passed**yesqa-003敏感数据**Score**0.40**Status**answered**Passed**yesqa-004资料不足**Score**0.55**Status**answered**Passed**yesqa-005差旅额度**Score**0.00**Status**abstained**Passed**yes它只证明当前五条问题可以被这份知识文件和算法区分默认阈值能回答四条已知问题未知差旅问题会拒答报告和测试可以重复运行。它没有证明对其他表达方式仍然有效能处理多段证据和冲突能安全接入真实内部资料能抵抗 Prompt Injection比语义检索或单次模型调用更好需要动态 Agent可以上线。更重要的是当前结果支持一个保守结论对这五条小型任务确定性检索已经够用现在还没有证据证明 Agent 能带来净收益。下一步不是为了让项目“更像 AI”而马上接模型而是扩充真实任务暴露控制组确实无法处理的决策需要组合多个来源资料冲突时需要比较新鲜度和权限工具失败后需要切换或恢复高风险动作需要暂停和审批不同任务需要不同检索与验证路径。只有这些任务出现并且 Agent 在等预算比较中改善结果升级才有依据。System Contract 不等于 Prompt、Schema 或 Agent Card几个概念容易混在一起。Prompt / Instructions**主要作用**指导当前模型行为**是否执行权限**否**是否定义完整系统责任**通常否Tool Schema**主要作用**描述一次工具调用的输入输出**是否执行权限**工具实现决定**是否定义完整系统责任**否JSON Schema**主要作用**校验数据结构**是否执行权限**否**是否定义完整系统责任**只覆盖声明结构A2A Agent Card**主要作用**服务发现与能力描述**是否执行权限**协议与实现决定**是否定义完整系统责任**否Model System Card**主要作用**说明模型能力、风险和评测**是否执行权限**否**是否定义完整系统责任**面向模型而非单一业务系统本文 Agent System Contract**主要作用**约定任务、边界、失败和证据**是否执行权限**否需 Runtime 强制**是否定义完整系统责任**是面向具体应用Google 对 A2A 协议的介绍说明A2A Agent Card 发布在约定 URL用于描述 Agent 名称、能力和端点。它更像服务的可发现接口。本文的卡片则是项目内部的责任接口。两者以后可以互相映射但不能因为名字相似就当成同一标准。什么时候不值得写一张复杂卡片System Contract 也不应该变成形式主义。下面这些任务可以使用更轻的定义一次性、只读、低风险的文本转换输入和输出完全固定的本地脚本已有成熟 API 合同和测试只增加一层自然语言入口不保存状态、不调用外部工具、不产生副作用的实验。这时最小版本可能只有代码Job:Input:Done:Boundary:Failure:Baseline:当系统开始具备下面任一条件再增加结构化和版本化会访问多个数据源会写入外部系统有拒答、接管或审批需要比较多个版本有多人或多服务共同维护失败会造成业务、隐私或资金风险。卡片的目标是减少解释成本和责任歧义不是追求字段数量。给自己项目的可复制模板可以直接下载agent-system-card.template.json也可以查看本文实验使用的真实 Contract。下面这份模板可以先放在仓库的contracts/agent-system-card.json代码{ id: your-agent-system, version: 0.1.0, job: { actor: 谁在使用, task: 替他完成什么现实工作, why_agent: 为什么固定脚本或工作流可能不足 }, input: { required: [最小输入], trusted_sources: [允许的数据来源], untrusted_sources: [必须按不可信处理的输入] }, done: { terminal_states: [completed, abstained], validators: [可执行或可人工复核的完成条件] }, boundaries: { allowed_actions: [当前可自动执行], prohibited_actions: [无条件禁止], approval_required: [批准后才可执行] }, failure: { terminal_states: [failed, handed_off], handoff_when: [冲突、超时、越权或高风险条件] }, evidence: { dataset: datasets/tasks.jsonl, primary_metrics: [现实任务指标], secondary_metrics: [延迟、成本、步骤或接管率] }, baseline: { strategy: 当前最简单可行方案, command: 可重复运行的命令, agent_required_if: 升级 Agent 必须证明的收益 }}填完后做四次交叉检查Done与Failure是否出现相同状态allowed、prohibited与approval是否互相冲突每个 Grader 条件是否能回到任务描述或安全策略why_agent是否只是“因为 Agent 很强”而没有可测量场景。45-60 分钟跟做练习选择一个你真的想做成 Agent 的任务例如提示词根据公司知识库回答工程问题审查 GitHub Issue 并生成修复建议调研一个主题并输出带引用报告整理客服请求并起草处理动作第一步写 Job 与非 Agent 基线10 分钟先不要写模型名。代码Actor:Task:Why Agent:Simplest Baseline:如果Why Agent只能写“回答更智能”继续缩小任务。第二步写完成、失败和边界15 分钟至少写出一个成功终态一个合法拒答或不适用终态一个失败终态一个需要人工接管的条件一个允许动作一个禁止动作一个需审批动作。第三步建立五条控制任务15 分钟建议分配提示词2 条正常任务1 条边界任务1 条资料不足任务1 条高风险或需接管任务把 Grader 条件写在任务里但不要把预期答案喂给被测系统。第四步运行最简单基线10 分钟可以是关键词检索SQL正则与模板固定 Workflow单次模型调用不给自主工具选择。记录每条任务的状态和失败原因。第五步做一次故意失败10 分钟任选一个删除必要合同字段让允许和禁止动作冲突把拒答阈值调到极端给 Grader 加一个任务没有说明的隐藏条件移除一份必要资料。如果失败后只能看到“没通过”却无法知道哪个任务、哪个条件、哪次运行出了问题证据层还不够。练习结束时你应该能用一句话说明提示词当前控制组在 ____ 条任务上通过 ____它失败在 ____只有 Agent 能在相同边界与预算下改善 ____ 时我才会升级。发布前检查清单任务描述的是现实工作而不是“做一个 Agent”。输入、成功、拒答、失败和人工接管都能区分。每个 Grader 条件在任务或策略中有依据。边界允许、禁止和需审批没有重叠。高风险动作由 Runtime 与人强制不只写在 Prompt。可信来源有版本、访问控制或来源证据。证据有一个不用 Agent 的控制组。每次运行能定位到任务、版本和失败原因。至少运行过一个故意失败的反例。没有把小型任务集的100%外推为生产可靠。升级能说清固定脚本或 Workflow 的能力上限。Agent 候选版本会在同一任务、边界和预算下比较。新增复杂度对应一个可测量收益。结语Agent 工程的第一步很容易被误认为“选择模型和框架”。这篇实验得到的结论更朴素提示词先定义它负责什么 → 再定义什么算完成与失败 → 把权限和人工权力写清楚 → 建立一个最简单控制组 → 用失败实验检查合同是否真的生效 → 最后才决定是否需要 Agent当前Agent Reliability Lab的确定性基线在五条教学任务上全部通过。这个结果不意味着系统已经可靠也不意味着 Agent 没有价值。它只让下一步问题变得准确我们需要加入哪些真实任务才能证明动态决策、工具使用和恢复能力确实比控制组更好学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】