上周有个朋友拿着一个 Agent 项目来问我。 他做的是代码变更助手用户提一句“给订单模块加一个优惠券核销能力”Agent 自动读代码、查接口文档、改代码、跑测试最后生成 PR。Demo 很顺。第一轮它能找到OrderService第二轮能补 DTO第三轮还能顺手生成单测。然后一接真实仓库问题全出来了。它读了 20 个文件以后开始忘记前面看过什么接口文档明明写着“核销接口需要幂等键”它生成的代码没有带工具调用到一半报权限错误它没有停下来反而继续用错误上下文写代码产品只说“优惠券核销”它自己脑补了退款逻辑。最后 PR 能跑但不能合。朋友问我“是不是模型不够强换一个更大的模型会不会好一点”我的判断很直接Agent 工程的核心不是把模型换大而是把 Token、Skill、RAG、MCP、SDD、Harness 这条链路搭稳。这些词不是六个并列概念。它们描述的是同一个系统从“能回答”走向“能交付”的六层约束Token 决定 Agent 当前能看见多少东西Skill 决定 Agent 遇到重复任务时按什么规矩做RAG 决定 Agent 缺知识时从哪里补证据MCP 决定 Agent 怎么安全、标准地接触外部系统SDD 决定 Agent 写代码之前有没有明确规格Harness 决定这些能力能不能稳定跑成一个闭环这篇文章就讲一个主问题为什么很多 Agent demo 很聪明一到工程交付就变蠢答案就在这条链里。TokenAgent 的工作台不是仓库先说最底层。Token 很容易被讲成计费单位这当然没错但做 Agent 时更应该把它理解成一个东西Agent 的工作台。模型这一次推理能参考的指令、历史对话、工具结果、代码片段、错误日志、检索材料都要摆在这张工作台上。工作台越大能同时处理的材料越多但它再大也不是无限仓库。现场问题代码库装不进上下文假设你让 Agent 修改订单模块。它一开始可能读这些文件src/order/OrderService.javasrc/order/OrderController.javasrc/order/dto/CreateOrderRequest.javasrc/coupon/CouponClient.javasrc/common/IdempotencyInterceptor.javadocs/coupon-api.mdlogs/test-failure.log看起来不多。但真实工程不是只读文件名。每个文件有代码每段代码有依赖每次测试失败又会产生新的日志。工具结果一轮轮塞进上下文很快就会挤掉旧信息。于是你会看到一种很典型的现象Round 1: Agent 发现 CouponClient.redeem() 需要 idempotencyKeyRound 2: Agent 修改 OrderService但没有传 idempotencyKeyRound 3: Agent 解释说“当前代码中未发现幂等要求”不是它没看过。是它看过的内容在多轮执行里被冲淡、截断、摘要错了或者被新的工具输出挤出了工作台。工程解法上下文要被管理不能靠运气OpenAI 的文档把 compaction 描述为一种把长对话压缩成摘要、避免超过上下文窗口的机制。这个动作在 Agent 里不是锦上添花而是基础设施。一个比较稳的上下文策略至少要有四件事动作解决什么问题工程实现分层读代码防止一次塞爆先读目录和符号索引再按任务选择文件摘要工具结果防止日志淹没关键信息长日志只保留失败用例、堆栈、关键断言固化决策防止多轮失忆把已确认约束写入agent-notes.md或任务状态库压缩上下文防止超过窗口超过阈值后把历史对话压成结构化摘要这里有一个很小的伪代码表达的是思想def build_context(task, state): context [] context.append(load_system_policy()) context.append(load_spec(task.spec_id)) context.append(load_task_state(task.id)) files retrieve_relevant_files(task.query, limit8) context.extend(summarize_if_large(file) for file in files) failures latest_test_failures(task.id) context.append(compact_logs(failures)) if token_count(context) state.max_context * 0.8: context compact_context(context, keep[spec, decisions, open_risks]) return context这段代码没有什么玄学。它只是在说一件事上下文不是聊天记录堆叠而是一次执行前主动组装出来的工作集。Token 这一层不稳后面的 RAG、工具调用、代码生成都会跟着抖。Skill把“每次提醒”变成“默认动作”Token 解决的是“看得见多少”。Skill 解决的是另一个问题看见以后按什么规矩做。很多人做 Agent喜欢把团队规范写进 prompt请遵守我们的代码规范1. Controller 不写业务逻辑2. Service 必须有单测3. 金额用 BigDecimal4. 日志不能打印手机号和身份证5. 外部接口必须加超时和重试第一次有效。第二次忘一半。第三次换个人写 prompt又变了。Skill 的本质可复用的操作手册Anthropic 的 Claude Skills 把技能定义成可被 Claude 加载的指令、脚本和资源集合。翻译成工程话就是把一类任务的做法沉淀成可复用包。比如一个 Java 后端代码修改 Skill可以长这样java-service-change/ SKILL.md scripts/ run_unit_tests.sh check_sensitive_logs.sh references/ error-code-convention.md transaction-boundary.mdSKILL.md不是写鸡汤而是写执行纪律# Java Service ChangeWhen changing service logic:1. Locate controller, service, repository, DTO, and tests before editing.2. Never put business logic in controller.3. Use BigDecimal for money.4. Add or update unit tests for changed branches.5. Run scripts/check_sensitive_logs.sh before final response.Stop and ask for review if:- The change needs a database migration.- The API contract is ambiguous.- Existing tests contradict the requested behavior.这比“请认真一点”强太多。因为它把团队的经验从一次性 prompt 变成了默认动作。Skill 和 Prompt 的区别对比项普通 PromptSkill生命周期当前对话可长期复用内容形态文字指令为主指令、脚本、模板、参考资料维护方式个人随手写项目级版本管理适合内容临时任务要求稳定流程和团队规范所以 Skill 不负责补业务知识。它负责让 Agent 在做同类事情时不要每次都重新学做人。RAG不是让模型“多读点”而是让答案有证据Skill 解决“怎么做”。RAG 解决“依据什么做”。你让 Agent 加优惠券核销Skill 可以告诉它“外部接口要加超时、错误码要统一、日志要脱敏”。但 Skill 不知道你们公司的优惠券接口今天改成了什么字段。这时候就要 RAG。RAG 最怕的是检索到一堆看似相关的垃圾很多 RAG 系统翻车不是因为没有检索。恰恰是因为检索太随意。比如用户问订单核销优惠券时幂等键应该怎么传一个粗糙的 RAG 可能返回1. coupon-api-v1.md老接口字段叫 requestId2. coupon-api-v2.md新接口字段叫 idempotencyKey3. refund-coupon.md退款返券逻辑也提到了 idempotencyKey4. marketing-campaign.md营销活动发券不是核销模型看到一堆材料很可能拼出一个“看起来合理但业务错误”的答案。这就是 RAG 幻觉的常见来源模型不是没有资料而是资料版本、范围、可信度混在一起了。工程解法RAG 要有过滤、重排和引用我更建议把 RAG 做成三段Query Rewrite - Retrieval - Rerank / Filter - Grounded Answer落到代码上大概是这样def retrieve_contract(question, module, version): query rewrite_query(question, hints{ module: module, doc_type: api_contract, version: version }) candidates hybrid_search( queryquery, filters{ module: module, status: active, doc_type: [api_contract, adr, test_case] }, top_k20 ) passages rerank(question, candidates, top_k5) return require_citations(passages)这里最关键的是三个细节filters先把过期文档、错模块文档过滤掉rerank再按问题相关性重排require_citations最后要求回答必须带引用不能凭感觉补RAG 的目标不是让模型显得懂很多。RAG 的目标是让模型每个关键判断都能落回证据。MCP工具调用从“手写适配”变成“协议接入”到这里Agent 已经能管理上下文也有规范和知识了。但它还只是会“想”和“写”。真要交付它必须接触外部系统Git、数据库、CI、工单、浏览器、对象存储、内部 API。这就进入 MCP。MCPModel Context Protocol官方定位是给 AI 应用连接外部工具和数据源的开放协议。它的价值不在于“又多一种调用工具的方法”而在于把工具接入标准化。Function Calling 和 MCP 不是一回事Function Calling 更像一次模型 API 调用里的工具声明{ name: get_order, description: Get order detail by order id, parameters: { type: object, properties: { orderId: { type: string } }, required: [orderId] }}这很好用但它通常是应用自己维护工具列表、认证方式、错误处理和服务连接。MCP 则更像一个标准插座。一个 MCP 系统里通常有三类角色Host用户实际使用的 Agent 应用ClientHost 内部负责维护连接的客户端Server暴露 tools、resources、prompts 的外部能力服务Agent 不需要在 prompt 里记住某个内部系统怎么调。它通过 MCP Server 发现能力再按 schema 调用。这解决的是工程治理问题比如你要接三个系统GitLab创建分支、提交 MR、读取 diffJira读取需求、更新状态、写评论CI触发流水线、读取测试结果如果全靠项目里手写 function calling很快会变成这样问题手写工具适配的后果认证分散每个工具一套 token 管理错误格式不同Agent 很难判断能不能重试权限边界不清读写能力混在一起工具描述漂移prompt 里写的和真实 API 不一致MCP 的意义就是把这些东西收敛到 Server 边界里。Server 负责暴露能力、描述 schema、处理认证、返回结构化错误Host 负责选择和调用。工程上会清爽很多。但也别把 MCP 神化。MCP 不能保证 Agent 调用得对它只是让“能调用什么、怎么调用、用什么权限调用”变得更标准。真正防止乱调用还要靠后面的 SDD 和 Harness。SDD先写规格再让 Agent 写代码Agent 最危险的地方不是它不会写。是它太会写。你给它一句模糊需求它也能写出一堆看起来完整的代码。这在 demo 里很好看在工程里很可怕。模糊需求会被模型自动补全还是优惠券核销这个例子。产品说订单支付前支持优惠券核销。如果没有规格Agent 可能会自己脑补核销失败是否阻断下单优惠券是否支持叠加支付失败后是否返还优惠券是否需要冻结库存是否需要幂等键是否要写操作日志这些不是代码细节。这是业务决策。Agent 不能替业务和架构师做这些决策。SDD 的价值把“猜”变成“按合同实现”SDDSpec-Driven Development规格驱动开发。GitHub 的 Spec Kit 也把“先规格、再计划、再任务、再实现”作为核心工作流。用在 Agent 工程里SDD 的关键不是多写文档而是建立一个门禁没有规格不进入实现。规格没评审不拆任务。任务没验收标准不让 Agent 自由改代码。一个最小规格可以这样写# Spec: 优惠券核销接入订单支付前置流程## Scope- 只支持单张优惠券- 只在订单支付前核销- 本次不处理支付失败后的返券## Rules- 核销请求必须携带 idempotencyKey- 核销失败时订单保持 CREATED不进入 PAYING- 同一订单重复提交时必须复用同一个 idempotencyKey- 日志不得打印用户手机号、优惠券完整码## Acceptance- 新增 CouponRedeemService 单测- 覆盖核销成功、核销失败、重复提交三个场景- 集成测试必须验证 OrderStatus 状态流转这份规格不长但它把 Agent 最容易乱猜的地方钉住了。更重要的是它让后面的验证变得可能。没有规格你只能问“代码写得好不好”。有规格你可以问“代码是否满足第 3 条验收标准”。Harness把模型包成一个可观测、可回滚、可审计的执行系统最后一层是 Harness。这个词中文很难一对一翻译可以理解成 Agent 的执行框架、脚手架、运行时外壳。如果说模型是发动机Harness 就是车架、仪表盘、刹车、方向盘、安全带和维修接口。没有 HarnessAgent 只是一轮轮调用模型。有 HarnessAgent 才是一个工程系统。一个生产 Agent 至少要有这些部件OpenAI Agents SDK 这类框架会把工具、handoff、guardrails、tracing 等能力放进 Agent 构建流程里。不同框架名字不完全一样但工程含义类似。我建议你按这张表理解 Harness部件作用没有它会怎样Planner拆任务和选择下一步Agent 想到哪做到哪Tool Registry管理工具 schema 和权限工具调用混乱Context Manager管理 Token 和压缩多轮执行失忆Guardrail输入输出和动作门禁危险操作直接执行Evaluator检查结果是否符合规格代码能跑但不符合需求Trace记录每一步决策和工具结果出错后无法复盘Human Approval人工审批敏感动作删库、发版、改权限无法兜底Harness 的执行循环一个比较实用的 Agent 循环大概长这样Load Spec - Build Context - Plan Next Step - Select Tool - Check Permission - Execute Tool - Record Trace - Evaluate Against Spec - Continue / Ask Human / Finish注意这里有两个门第一道门在工具执行前。if tool.name in [delete_branch, run_migration, deploy_prod]: require_human_approval(tool_call)第二道门在执行结果后。result evaluate_against_spec( specload_spec(task.spec_id), diffgit_diff(), testslatest_test_result())if result.has_blocker: agent.replan(result.feedback)这两道门决定了 Agent 是“帮你干活”还是“替你制造事故”。Harness 真正难的是副作用治理问答机器人答错一句大不了重新问。Agent 调错一个工具可能会创建错误 PR、改错数据库、触发错误流水线、把错误状态同步到工单系统。所以 Harness 一定要把副作用分级动作级别示例策略只读读文件、查文档、查 CI 日志默认允许记录 trace可回滚写改本地文件、创建草稿 PR自动执行但保留 diff外部写更新工单、评论 MR需要明确任务上下文高风险写发版、迁移、删除、权限变更人工审批很多 Agent 项目不稳定不是模型不会推理而是 Harness 没有把这些边界管住。六层放在一起Agent 才从 demo 变成系统现在回头看这六个概念它们不是概念墙。它们是一条链。Token - Skill - RAG - MCP - SDD - Harness每一层都在回答一个工程问题层核心问题典型故障Token当前执行能看见什么多轮失忆、上下文污染Skill重复任务按什么规矩做产出风格不一致、规范遗漏RAG缺知识时引用什么证据引用旧文档、一本正经胡说MCP怎么连接外部系统工具碎片化、权限混乱SDD写代码前规格是否清楚需求跑偏、模型脑补业务Harness执行过程是否可控不可观测、不可回滚、不可审计这张表也可以当排查清单。Agent 忘了前面约束先看 Token 和 Context Manager。Agent 每次代码风格不一样先看 Skill。Agent 答案没依据先看 RAG 检索和引用。Agent 工具越来越难维护先看 MCP 或工具注册表。Agent 写出来不是你要的先看 SDD。Agent 时好时坏、出错说不清先看 Harness。工程落地一个小团队怎么开始如果你现在手上只有一个普通代码助手不要一上来就搭大平台。我建议按这个顺序做。第一阶段先管住上下文和规格这是投入最小、收益最大的两件事。为每个任务创建spec.md为每次执行创建agent-state.md让 Agent 每轮开始前读取规格和状态让 Agent 每轮结束后更新已确认约束、已修改文件、未解决风险目录可以很简单.agent/ tasks/ coupon-redeem/ spec.md plan.md agent-state.md trace.md这一步做完你会发现 Agent 稳很多。因为它不再完全靠对话历史记忆任务。第二阶段沉淀 Skill 和 RAG把稳定规范变成 Skill把变化知识放进 RAG。不要反过来。代码规范、安全检查、错误码约定、测试要求这些适合 Skill。接口文档、数据库表结构、历史 ADR、线上故障复盘这些适合 RAG。一个简单原则三个月不怎么变的放 Skill每周都可能变的走 RAG。第三阶段工具接入标准化当你发现工具越来越多就该抽工具层了。不一定所有团队第一天都要上 MCP。但你至少要做到工具 schema 清楚错误码结构化读写权限分开高风险动作可审批每次工具调用有 trace如果你的 Agent 要接多个外部系统或者要给多个客户端复用工具能力MCP 的价值会明显变大。第四阶段补 Harness 的观测和评估最后才是更完整的 Harness。你需要开始关心指标指标含义task_success_rate任务最终通过验收的比例human_intervention_rate需要人工介入的比例tool_error_rate工具调用失败比例spec_violation_count违反规格的次数token_per_task单任务 Token 成本rollback_count需要回滚的执行次数这些指标比“模型回答看起来聪明”有用。因为工程交付看的不是一次高光而是稳定成功率。面试怎么答如果面试官问你“你怎么理解 AI Agent 的核心架构”不要只回答“LLM Tools Memory Planning”。这个回答不算错但太像背概念。你可以这么说★我会把 Agent 工程拆成六层。最底层是 Token它决定一次执行能看见什么所以要做上下文组装、压缩和外部状态记录。第二层是 Skill把团队稳定的操作流程封装起来避免每次靠 prompt 临时提醒。第三层是 RAG给 Agent 补动态知识但重点不是多检索而是过滤、重排、引用和版本控制。第四层是 MCP 或工具协议层解决 Agent 连接外部系统时的标准化、权限和可发现性问题。第五层是 SDD先把需求边界、验收标准和非功能约束写成规格再让 Agent 实现防止模型脑补业务。最上层是 Harness也就是执行框架负责规划、工具注册、上下文管理、权限门禁、评估、trace 和人工审批。这六层串起来Agent 才不是一个会聊天的模型而是一个可观测、可回滚、可审计的工程系统。如果面试官继续追问“你们项目里最容易出问题的是哪层”可以答★最容易被低估的是 SDD 和 Harness。很多团队以为 Agent 跑偏是模型问题其实是规格不清以为工具调用错是 prompt 问题其实是 Harness 没有做权限、trace 和评估。模型能力当然重要但生产环境更看重边界和闭环。这个回答会比“我们用了 RAG 和 Function Calling”扎实很多。回到开头那个 PR朋友那个代码变更助手后来没有先换模型。他们先做了三件小事每个需求先生成spec.md人工确认后再实现每轮执行把关键约束写进agent-state.md对 Git、CI、工单工具做读写权限分级高风险动作必须审批效果很朴素。Agent 还是会犯错但错得更早、更小、更容易复盘。这就是 Agent 工程真正要追求的状态。不是让模型一次性变成全能程序员。而是用 Token 管理、Skill、RAG、MCP、SDD 和 Harness把一个不确定的模型包进一个确定性更强的工程系统里。概念讲到最后其实就一句话Agent 的上限来自模型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%免费】