想象你要开一家智能餐厅。你不必亲自掌勺,但必须把这家店从一句想法变成能稳定出餐的完整系统:先问清楚客人吃什么、有什么忌口,画出后厨动线和岗位分工,给主厨配齐菜谱和厨具,每道菜出餐前先试吃,最后根据客人反馈不断改良菜单。这套经营思路,正是“用 AI 开发 AI Agent”的真实写照——业内把它叫做 Vibe Coding,意思是像聊天一样让 AI 替你写代码。 然而,聊天式开发并不等于随口指挥:需求含糊、架构缺失、工具乱接、测试缺位,都会让 AI 生成的 Agent 像一家食材乱放、厨师没培训的餐厅,开业即翻车。本文会带你完整走一遍 AI Agent 自主开发工作流:从需求拆解、架构设计、代码生成、工具集成,到测试验证、迭代优化,用一条可复制的流水线,把“让 AI 写一个 Agent”从碰运气变成确定性工程。

岗位关联

掌握这套工作流,你将完成从“能问 AI 要代码”到“能带 AI 交付产品”的跨越,这是 AI 时代工程师最值钱的能力之一。

目录
  1. 可视化演示
  2. 需求拆解——先让菜单上的每一道菜写得明明白白
  3. 架构设计——给后厨定岗位、排动线
  4. 代码生成——照菜谱备料,小步出菜
  5. 工具集成——给 Agent 接上厨具和食材柜
  6. 测试验证——出餐前必试菜,不能省
  7. 迭代优化——根据客人反馈改良菜单
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示AI Agent开发完整流程:需求拆解四步法、单Agent与多Agent架构设计、工具调用集成测试、迭代优化与部署监控。支持步进切换四种模式。

本节配有交互动效(进入视口后自动加载,约 3KB)。

'+captions.req+'

需求拆解——先让菜单上的每一道菜写得明明白白

顾客走进餐厅只说一句“来点好吃的”,再厉害的厨师也会懵在原地。需求拆解,就是把你那句“我想做一个能自动写日报的 Agent”翻译成一份可执行的菜单:原料是什么、口味什么要求、出餐时限多久。只有把需求拆成一条条清晰、独立、可验证的小任务,后厨才敢开火,做的菜才是客人真正想吃的。

在 AI Agent 开发里,这一步决定了后面所有环节的质量。拆得清楚的需求,进入提示词工程时能被 Agent 完整理解;拆得含糊的需求,Agent 生成的代码常常实现的是另一个东西。所以工作流的第一步,永远是面向“人机共识”的需求拆解,而不是急着让 AI 动手写代码。

需求拆解要输出三样东西:用户故事(谁在什么场景下需要什么)、验收标准(怎么算做完)、任务清单(按优先级排列的子任务)。用户故事让 Agent 理解业务意图;验收标准让测试环节有据可依;优先级排序决定先生成哪个模块。主需求 R 被拆解为 n 个子任务 r_i,每个子任务必须同时包含目标 G_i 和验收条件 A_i,二者缺一则无法闭环。

就像菜单上每道菜写清楚食材克数和火候,拆解后的需求清单让 AI 不必“猜”你要什么。猜得越少,返工越少。下一节,我们把这份菜单变成后厨的布局图。

R=⋃i=1nri,ri=(Gi,Ai)R = \bigcup_{i=1}^{n} r_i, \quad r_i = (G_i, A_i)
一个需求只有拆到“每个子任务都有明确目标和验收标准”时,AI 才能像厨师照着菜谱做菜一样稳定交付。
  1. R(完整需求集)把整个需求看成一个集合,它由若干子任务拼装而成,标注 R 表示需求的全部范围。
    RR
  2. 并集运算 ∪子任务之间是“并”的关系,全部完成才算需求整体交付,缺一个都算没做完。
    ⋃i=1n\bigcup_{i=1}^{n}
  3. 子任务 r_i拆解后的每个小任务,对应菜单上的一道菜,能被单独实现和单独验收。
    rir_i
  4. 二元组 (G_i, A_i)每个子任务由目标 G 和验收标准 A 组成,目标定方向、验收定终点,缺一不可。
    (Gi,Ai)(G_i, A_i)

架构设计——给后厨定岗位、排动线

餐厅后厨不能只有一口锅。谁切配、谁掌勺、谁传菜,每个岗位各司其职,动线才顺畅。Agent 的架构设计也是同理:先把想要的能力拆成组件,再决定组件之间怎么协作、边界在哪里,而不是直接往代码编辑器里灌需求。

Agent 的经典能力公式是“Agent = LLM + 提示词 + 工具 + 记忆”。LLM 是大脑,提示词是工作手册,工具是手脚,记忆是经验台账。架构设计的核心就是回答四个问题:角色怎么规划(这个 Agent 是客服还是运维?)、工具怎么选型(需要哪些外部能力)、数据流怎么走(输入输出如何流转)、提示词怎么写(如何约束模型的行为边界)。

把“厨房动线图”画好后,主厨(AI)才知道什么时候开火、什么时候出锅。架构先行、代码后写,是确定性开发区别于“瞎试”的起点,也是后面每一行代码的施工蓝图。

Agent=LLM⏟大脑+Prompt⏟菜谱+Tools⏟厨具+Memory⏟经验\mathrm{Agent} = \underbrace{\mathrm{LLM}}_{\text{大脑}} + \underbrace{\mathrm{Prompt}}_{\text{菜谱}} + \underbrace{\mathrm{Tools}}_{\text{厨具}} + \underbrace{\mathrm{Memory}}_{\text{经验}}
架构设计不是画 PPT,而是把 Agent 的认知、行为、记忆和工具边界先圈定,后续代码生成才有据可依。
  1. LLM(大模型)Agent 的“大脑”,负责理解用户意图、做推理和决策,是整个系统最核心的认知部件。
    LLM\mathrm{LLM}
  2. Prompt(提示词)写给大脑的“菜谱”,通过角色设定、步骤说明和约束条件,把模型调教成特定岗位的员工。
    Prompt\mathrm{Prompt}
  3. Tools(工具)大脑的“手脚”,通过函数调用与外部 API 交互,让 Agent 不止会聊天还会干活。
    Tools\mathrm{Tools}
  4. Memory(记忆)Agent 的“经验台账”,保存跨对话状态与业务知识,是长周期任务不回潮的关键。
    Memory\mathrm{Memory}

代码生成——照菜谱备料,小步出菜

菜单有了、动线画好了,后厨开始备料。代码生成阶段,AI 主厨按你的提示词“菜谱”逐道出菜。优秀的做法不是让它一口气做一桌满汉全席,而是一道一道来:先搭脚手架(备料台),再实现核心模块(主菜),边做边让你试吃(代码审查),吃完了同步更新文档(菜谱存档)。

Vibe Coding 的一个关键指标是“首次通过率”——AI 一次生成的代码能直接跑通、不用返工的比例。上下文给得越完整、模块拆得越小、反馈越及时,首过率就越高。反过来,把 2000 行需求一次性丢给 AI,生成的代码往往要反复修复,返工成本远高于“小步快跑”。

每出一道菜就试吃一次,比全部做完再返工省十倍时间。代码生成不是一锤子买卖,而是“小步生成—立即验证—继续下一模块”的闭环,让 AI 的每一次出力都落在可见的成果上。

P首过=N通过N总×100%P_{\text{首过}} = \frac{N_{\text{通过}}}{N_{\text{总}}} \times 100\%
首次通过率衡量“一次说清”的能力:上下文越清晰、模块越小,AI 一次做对的概率越高,返工成本越低。
  1. P_首过(首次通过率)一次生成且无需返工就能跑通的代码占比,是衡量提示词质量与拆分粒度的重要指标。
    P首过P_{\text{首过}}
  2. 分子 N_通过AI 本轮生成的所有代码块中,第一次就直接可用的数量,数量越大说明生成质量越高。
    N通过N_{\text{通过}}
  3. 分母 N_总AI 本轮生成的全部代码块数量,包含通过的和需要修复的,构成计算比例的基础。
    N总N_{\text{总}}
  4. ×100%把两个数的比值换算成百分数,方便在不同模块、不同版本之间横向对比,直观反映效率波动。
    ×100%\times 100\%

工具集成——给 Agent 接上厨具和食材柜

光有菜谱不顶用,厨师得能开火、能开冰箱。Agent 的工具集成,就是给它接上“手和脚”:查天气、读文件、调数据库、发请求……这些能力通过函数调用(Function Calling)暴露给大模型。所谓函数调用,可以理解成让模型学会“点名”——在回答问题时主动说“我要调用某某工具”,然后系统替它执行。

工具集成要处理四件事:API 对接(把外部服务封装成标准函数)、函数调用(让模型在恰当时候选中工具)、记忆存储(把历史信息持久化保存)、权限控制(防止 Agent 越权访问敏感资源)。工具不是越多越好:每多一个工具,模型“选错工具”的概率就高一分,所以工具清单要像厨具架一样分类摆放、按需取用。

好的厨房不是厨具最多的厨房,而是每件工具都顺手、随手可得的厨房。权限控制就像带锁的食材柜——该开放的开放,不该碰的坚决锁住,让 Agent 在能力边界内自由发挥。

Agent(q)→识别tooli→执行Result→回答\mathrm{Agent}(q) \xrightarrow{\text{识别}} \mathrm{tool}_i \xrightarrow{\text{执行}} \mathrm{Result} \rightarrow \text{回答}
工具调用是一条“识别—执行—回填”的链路:Agent 先判断该用哪个工具,执行后拿到结构化结果,再组织成自然语言回答。
  1. Agent(q)用户把问题 q 交给 Agent,整个工具调用工作流以此为起点,等待模型做出调用决策。
    Agent(q)\mathrm{Agent}(q)
  2. 识别 tool_iAgent 从注册好的工具清单里选中与当前问题最匹配的那一个,相当于厨师决定“这道菜用哪个锅”。
    →识别tooli\xrightarrow{\text{识别}} \mathrm{tool}_i
  3. 执行并返回 Result外部系统执行该工具,把结构化结果交回 Agent,这是 Agent“动手干活”的关键一跳。
    →执行Result\xrightarrow{\text{执行}} \mathrm{Result}
  4. 生成回答Agent 把工具返回的结果翻译成用户能看懂的答案,至此完成一轮完整的“想—做—说”闭环。
    →回答\rightarrow \text{回答}

测试验证——出餐前必试菜,不能省

再熟练的主厨,出餐前也要试菜;米其林餐厅甚至会检查每道菜的摆盘与温度。Agent 上线前同样必须经过测试验证,否则一个没被发现的 bug 可能在线上演变成事故——毕竟 Agent 面对的是无法预演的开放场景。

测试验证分四层:单元测试(验证单个函数行为)、集成测试(验证模块间协作)、边界用例(故意输入异常值,考验 Agent 的鲁棒性)、安全审计(检查提示词注入和越权路径)。自动化测试代码可以交给 AI 生成,但断言逻辑必须人肉确认——AI 自证清白不等于真的清白。

试菜的目的不是“证明菜能吃”,而是“确保每一道菜都稳定好吃”。边界用例和安全审计就像后厨的消防演习——平时用不上,出事就晚了,所以一次都不能省。

Coverage=NpassNtotal×100%\mathrm{Coverage} = \frac{N_{\text{pass}}}{N_{\text{total}}} \times 100\%
覆盖率是发布前的“体检单”:核心链路覆盖不到的测试等于没测;覆盖率不是越高越好,但关键路径必须达标。
  1. Coverage(覆盖率)衡量测试对功能点和代码路径的覆盖程度,是发布评审中最直观的质量门禁之一。
    Coverage\mathrm{Coverage}
  2. 分子 N_pass执行后验证通过的用例数量,体现代码的正确程度与测试断言的严格程度。
    NpassN_{\text{pass}}
  3. 分母 N_total设计好的全部用例数量,包含正常用例、边界用例和异常用例,代表测试的完整程度。
    NtotalN_{\text{total}}
  4. ×100%把通过数与总数之比转成百分数,与团队设定的发布门槛(比如 80%)直接比较,决定能否放行。
    ×100%\times 100\%

迭代优化——根据客人反馈改良菜单

开业第一天客人说“太咸了”,第五天说“上菜太慢”。这些反馈,就是餐厅迭代的燃料。Agent 上线后同样需要持续迭代优化:收集真实使用反馈、分析性能瓶颈、快速回滚失败版本、管理好每一代版本,让 Agent 越用越稳、越用越聪明。

迭代优化的核心是“质量与反馈的闭环”:当前版本质量 Q_t 加上一轮反馈修正量 ΔQ,得到下一版本质量 Q_{t+1}。反馈修正量来自三处——用户行为数据(哪些请求失败)、测试补充(哪里覆盖不足)、评审意见(提示词哪里误导了模型)。性能分析定位短板,失败回滚保证止损,版本管理让每次改动可追溯、可回退。

餐厅的招牌菜是一版一版试出来的,Agent 的稳定可靠也是一轮一轮迭代出来的。菜单会换、厨具会换、厨师也会换,但“拆解—架构—生成—集成—测试—迭代”这条流水线,才是餐厅真正的核心竞争力。

Qt+1=Qt+ΔQ反馈Q_{t+1} = Q_t + \Delta Q_{\text{反馈}}
迭代不是原地重试,而是带着高质量反馈向前走;没有反馈的循环像推磨,有反馈的循环才能滚雪球。
  1. Q_t(当前质量基线)第 t 轮版本当前的质量水平,是新一轮迭代的起点,对应“现在餐厅的招牌菜有多好吃”。
    QtQ_t
  2. Q_{t+1}(下一版本质量)经过一轮迭代后的目标质量,它必须比当前版本更高,否则迭代就没有意义。
    Qt+1Q_{t+1}
  3. ΔQ_反馈(反馈修正量)来自评审、测试和用户反馈的有效改进之和,是质量提升的真正引擎,可正可负。
    ΔQ反馈\Delta Q_{\text{反馈}}

AI 应用场景

需求工单自动转代码流水线

阶段:需求拆解 + 代码生成

解决的问题:传统 Jira 工单到代码要经过产品、研发多轮沟通,上下文丢失严重。AI Agent 接收工单后,自动按“用户故事—验收标准—任务清单”拆解需求,生成带测试的代码 PR,工程师只做评审和合并,把重复劳动降到最低。

具体案例:某中型互联网团队用 Claude Code 接入内部工单系统,每周自动消化 30 多个小需求,研发人均交付量提升约 2 倍,代码首次通过率从 30% 提升到 65%。

回归测试 Agent 守护发布门禁

阶段:测试验证

解决的问题:每次发版都要人工补回归用例,漏测率高、耗时长。AI 回归测试 Agent 根据历史缺陷和需求变更自动生成边界用例,跑完自动汇总覆盖率报告,低于门槛直接拦截发布。

具体案例:某金融科技团队引入测试 Agent 后,核心系统回归测试从 2 天缩短到 4 小时,边界用例数量翻倍,线上漏测事故减少 70%。

运维告警自愈 Agent

阶段:工具集成 + 迭代优化

解决的问题:凌晨的告警邮件无人响应,等人工到场业务已受损。运维 Agent 通过函数调用集成监控 API、日志查询和故障隔离工具,收到告警后自动诊断、定位、执行预设修复动作,并在失败时回滚到上一稳定版本。

具体案例:某电商平台在促销高峰用自愈 Agent 处理缓存抖动告警,平均发现到恢复时间从 25 分钟降到 3 分钟,且每次修复都会沉淀为新的工具调用模板,持续迭代优化。

Python 演示

python69 行
# -*- coding: utf-8 -*-"""极简 AI Agent 开发工作流演示:需求拆解 -> 工具调用 -> 验收校验"""import jsonimport re  def parse_requirement(text):    """需求拆解:提取目标和验收标准"""    goal = re.search(r"目标是(.+?),", text)    accept = re.search(r"验收标准是(.+)", text)    return {        "goal": goal.group(1) if goal else text,        "acceptance": accept.group(1) if accept else "结果不为空",    }  def plan_tasks():    """架构设计:输出有序任务清单,等价于先设计再执行"""    return [        {"name": "提取关键词", "tool": "keyword_extract"},        {"name": "生成结果", "tool": "make_list"},        {"name": "校验验收", "tool": "check_output"},    ]  def keyword_extract(goal):    """工具一:从目标中切出关键词"""    return [w.strip() for w in goal.split() if w.strip()]  def make_list(keywords):    """工具二:生成偶数列表作为示例结果"""    return [i * 2 for i in range(5)]  def check_output(result):    """工具三:验收函数,判断结果是否满足标准"""    return len(result) > 0  TOOLBOX = {    "keyword_extract": keyword_extract,    "make_list": make_list,    "check_output": check_output,}  def agent_loop(text):    """Agent 主循环:串行调用工具,记录各步骤日志"""    req = parse_requirement(text)    carried = {"goal": req["goal"], "acceptance": req["acceptance"]}    log = []    for step in plan_tasks():        fn = TOOLBOX[step["tool"]]        if step["tool"] == "keyword_extract":            carried["keywords"] = fn(carried["goal"])        elif step["tool"] == "make_list":            carried["output"] = fn(carried["keywords"])        else:            carried["passed"] = fn(carried["output"])        log.append({"step": step["name"], "status": "ok"})    return carried, log  if __name__ == "__main__":    REQUIREMENT = "目标是生成偶数列表,验收标准是结果不为空"    result, steps = agent_loop(REQUIREMENT)    print(json.dumps(result, ensure_ascii=False, indent=2))    print("执行步骤数:", len(steps))
目的:用 60 行代码演示“需求拆解 → 架构设计 → 函数调用 → 验收校验”的 Agent 最小工作循环,跑通一次完整的自主任务。
  1. def parse_requirement(text):需求拆解:从自然语言里提取目标和验收标准,对应工作流第一环节。
  2. TOOLBOX = {...}工具注册表:把函数名映射到实现,等价于工作流里的“工具集成”。
  3. for step in plan_tasks():主循环:按架构设计阶段排好的任务清单逐个执行,对应“架构设计”输出。
  4. fn = TOOLBOX[step["tool"]]函数调用:通过名字找到真实函数并执行,是 Function Calling 的简化版。
  5. carried["passed"] = fn(carried["output"])测试验证:用验收函数校验结果,对应“测试验证”环节。

常见误区

误区我觉得只要把想要的功能描述得非常详细,AI 就能一次性写对。拆需求是给不会用 AI 的人准备的,太啰嗦,直接描述不就行了?

正解详细描述不等于需求拆解。拆解是把一个大目标切成一连串有验收标准的小任务,每个任务能独立验证、独立回退。给 AI 一大段详细描述,它生成时依然会“顾此失彼”,一旦出错还很难定位。把需求拆成“用户故事 + 验收标准”,AI 才能像厨师照着分步菜谱做菜,而不是凭感觉乱炖。

为何常见:聊天式 AI 给人一种“你只管说、我来搞定”的错觉,让人忽略了它本质是概率预测——输入越长,中间的关键信息越容易被稀释。

误区Agent 框架遍地都是,模型自己就能决定怎么组织工具和角色,人工设计架构纯属多余,直接让 AI 自己搭不就行了?

正解框架给的是空壳,角色规划、工具选型、数据流设计和提示词边界必须由人来定。AI 只能在你给定的框架内做局部优化,无法替你做出业务判断。好比餐厅可以请顶级主厨,但开川菜还是粤菜、动线怎么排,必须老板拍板,厨师不能替你决定经营方向。

为何常见:框架的宣传语强调“开箱即用”,让人误以为架构设计已经被框架完全替代,实际上框架只是空厨房。

误区多接几个 API、多配几个工具,Agent 什么都能干,肯定更强。反正有大模型兜底,工具越多选择越灵活。

正解工具越多,模型在“选哪个工具”上的出错率越高,还可能把参数填错。工具集成追求的是“按需、可控、可观测”:每个工具都要有清晰的功能描述和权限边界,最好先小规模试用再逐步接入。厨具架上堆满杂物,厨师反而找不到盐。

为何常见:功能清单看起来越丰富越有安全感,但 Agent 的选型决策是基于概率的,选项越多越容易混淆,反而摊薄了每个工具的可靠性。

误区AI 生成代码,AI 生成测试,全部自动跑完绿了就上线,人完全不用管,自动化流程不就是这样吗?

正解AI 生成的测试容易与实现“共谋”——它测试的是自己写的逻辑,而不是需求本身。边界用例、安全审计、验收标准的制定必须有人参与。测试的目标是验证“满足需求”,而不是“运行不报错”。自动执行 ≠ 自动判断质量,试菜的人不能是炒菜的人。

为何常见:CI/CD 全自动流程深入人心,容易把“自动执行测试”误解成“自动判断质量”,忽略了判断标准需要人来定义。

误区生成失败就继续让 AI 试,多试几次总能过,反正 token 便宜,重试到通过不就行了?

正解盲目重试不仅不收敛,还可能让模型在错误方向上越走越远。真正的迭代是“收集反馈→定位根因→修正上下文→小步验证”,必要时回滚到稳定版本再出发。没有反馈信号的重试,等于蒙眼推磨;只有带着高质量反馈的迭代,才能像滚雪球一样让质量持续增长。

为何常见:生成式 AI 的随机性让人觉得“再来一次”总有希望,但忽略了随机性必须靠反馈信号来收敛,而非靠重复次数堆砌。

面试题

Q1. Vibe Coding 最核心的特征是什么?

单选题 · easy

  • A.靠自然语言让 AI 生成并迭代代码← 正确答案
  • B.完全放弃代码审查与测试流程
  • C.用低代码平台拖拽搭建界面
  • D.只编写测试用例不写业务代码

答案:A。Vibe Coding 的核心是“用自然语言驱动 AI 写代码并快速迭代”,A 正确。B 错误:审查与测试不能放弃,只是方式在改变。C 是低代码拖拽路线,与生成式编程有本质区别。D 与 Vibe Coding 相悖——业务代码正是要生成的对象。

Q2. Agent 能力公式中“记忆”主要解决什么问题?

单选题 · easy

  • A.让 Agent 跨对话记住上下文← 正确答案
  • B.提升大模型的数学计算速度
  • C.降低每次调用的费用成本
  • D.替代人工编写测试用例

答案:A。记忆对应公式 Agent = LLM + Prompt + Tools + Memory 中的 Memory,解决跨对话、跨任务的状态保存问题,像餐厅的客人档案。B 是模型自身能力问题,C 是成本优化问题,D 属于测试环节,都与记忆无关。

Q3. 需求拆解时“验收标准”的作用是什么?

单选题 · mid

  • A.提供任务完成的判定条件← 正确答案
  • B.提升代码运行时的内存效率
  • C.替代架构设计环节的工作
  • D.减少模型参数量的规模

答案:A。验收标准回答“怎么算做完”,是需求拆解阶段为每个子任务设定的终点,也是测试和交付的依据。B 是运行性能问题,C 混淆了拆解与架构的职责边界,D 与需求拆解毫无关系。

Q4. 函数调用(Function Calling)在 Agent 中充当什么角色?

单选题 · mid

  • A.把大模型与外部工具连接起来← 正确答案
  • B.提升大模型的训练数据质量
  • C.压缩上下文窗口的长度限制
  • D.自动生成前端页面的样式

答案:A。函数调用是工具集成的基础机制:模型输出结构化调用指令,系统找到并执行对应工具,再把结果回填给模型,从而让 Agent“动手干活”。B 涉及训练环节,C 涉及上下文优化,D 只是前端生成,都不是函数调用的职责。

Q5. 测试覆盖率公式 Coverage = N_pass / N_total 中,分母表示什么?

单选题 · mid

  • A.全部测试用例或代码的总数← 正确答案
  • B.通过测试的用例数量统计
  • C.失败用例的数量统计结果
  • D.被验证功能的代码行数

答案:A。覆盖率 = 通过数 / 总数,分母 N_total 是全部测试用例或代码路径的总数,分子 N_pass 才是通过数。B、C 都只是公式里的一个变量,D 是覆盖率的一种统计口径变体,均不是分母定义。

Q6. 迭代优化时“失败回滚”的核心目的是什么?

单选题 · hard

  • A.快速恢复到稳定版本再继续改进← 正确答案
  • B.删除所有历史版本的信息
  • C.让 AI 无限重试直到成功
  • D.降低日志输出的频率

答案:A。回滚是为了止损并保留改进基线:先回到稳定的 Q_t,再带着有效反馈重新出发。B 删除历史版本会丢失回溯能力,与版本管理理念相反。C 是盲目重试的典型误区,D 与回滚毫不相关。

Q7. 工具集成中“权限控制”主要防范什么风险?

单选题 · mid

  • A.Agent 越权调用敏感命令或数据← 正确答案
  • B.模型生成的代码行数过长
  • C.提示词中中文字符过多
  • D.测试用例数量不足导致遗漏

答案:A。权限控制给每个工具划定访问边界,防止 Agent 被提示词注入后调用危险命令或读取敏感数据,相当于给食材柜上锁。B 是代码长度问题,C 是文本编码问题,D 是测试覆盖问题,均与权限无关。

Q8. 以下哪些是 AI Agent 开发工作流的环节?

多选题 · easy

  • A.需求拆解← 正确答案
  • B.架构设计← 正确答案
  • C.测试验证← 正确答案
  • D.数据标注

答案:ABC。完整工作流包含需求拆解、架构设计、代码生成、工具集成、测试验证、迭代优化六大环节,A、B、C 都在其中。D 数据标注属于模型训练侧的工作,不属于 Agent 应用开发工作流。

Q9. 架构设计阶段需要确定哪些内容?

多选题 · mid

  • A.Agent 的角色与分工规划← 正确答案
  • B.外部工具的选型方案← 正确答案
  • C.模块间数据流设计← 正确答案
  • D.服务器采购价格预算

答案:ABC。架构设计要回答角色规划、工具选型、数据流设计和提示词边界四个问题,A、B、C 正是其中三项。D 采购预算是运维成本决策,不在架构设计的职责范围内。

Q10. 提高代码生成“首次通过率”的可行手段有哪些?

多选题 · hard

  • A.提供完整清晰的上下文← 正确答案
  • B.小步迭代并及时修正← 正确答案
  • C.任务拆解后逐模块生成← 正确答案
  • D.一次性生成全部代码避免交互

答案:ABC。完整上下文让 AI 少猜、小步迭代让错误早暴露、逐模块生成让每个模块独立验收,三者都能显著提升首过率。D 恰恰相反:一次性生成大量代码会稀释模型注意力、放大错误,是典型的反面做法。