6.3 典型应用案例分析
6.3 典型应用案例分析
本节约处在第六章第三站。前面讲了一堆能力，这一节把它们聚成几个"可对标"的真实范式。每个范式都对应一类业务形状：多源调研、内容生产、代码辅助。先看一张"调研型 Crew"的链路，它几乎是最常见的落地样子。
范式一：多源调研 Crew。把"
范式一：多源调研 Crew。把"检索、取数、核查、撰写"分给四个角色，前三者扇出并行，核查卡质量，最后撰写汇聚。这正是第一章 1.2 提过的甜区。代码骨架如下：
from crewai import Agent, Task, Crew, Process researcher = Agent(role="检索", goal="搜新闻", backstory="快", tools=[search], verbose=True) analyst = Agent(role="取数", goal="查指标", backstory="准", verbose=True) checker = Agent(role="核查", goal="验出处", backstory="挑剔", verbose=True) writer = Agent(role="撰写", goal="成稿", backstory="连贯", verbose=True) t_r = Task(description="搜 {topic} 新闻", expected_output="要点", agent=researcher, async_execution=True) t_a = Task(description="查 {topic} 指标", expected_output="数字", agent=analyst, async_execution=True) t_c = Task(description="核查 r 与 a 的出处", expected_output="通过/存疑", agent=checker, context=[t_r, t_a]) t_w = Task(description="据核查结果写报告", expected_output="报告全文", agent=writer, context=[t_c]) crew = Crew(agents=[researcher, analyst, checker, writer], tasks=[t_r, t_a, t_c, t_w], process=Process.sequential) # 6.3 典型应用案例分析
范式二：代码辅助 Crew。读仓库、提方案、写补丁、做评审分给不同角色，利用各自工具（读文件、跑测试、调 lint）。难点在"评审"角色要能跑测试拿到真实反馈，所以给它接执行类工具并加人工确认（红线见 5.5）。
reader = Agent(role="读代码", goal="定位相关模块", backstory="熟悉架构", verbose=True)
patcher = Agent(role="写补丁", goal="实现修改", backstory="谨慎", verbose=True)
reviewer = Agent(role="评审", goal="跑测试验补丁", backstory="严格", tools=[run_tests], verbose=True)
t_read = Task(description="定位 {issue} 相关文件", expected_output="文件清单", agent=reader)
t_patch = Task(description="实现修复", expected_output="补丁 diff", agent=patcher, context=[t_read])
t_review = Task(description="运行测试验证补丁", expected_output="通过/失败+原因", agent=reviewer, context=[t_patch])
crew = Crew(agents=[reader, patcher, reviewer], tasks=[t_read, t_patch, t_review],
process=Process.sequential, verbose=True)
## 范式三：内容生产流水线。选题、写 范式三：内容生产流水线。选题、写大纲、成稿、审校串成顺序流，每步产出格式钉死，适合批量产出（如电商详情、社媒文案）。这类最容易规模化，也最该上测试（见 5.3）守格式。 这些范式的共性不是"用了多少角色"，而是三点：任务能切、每段能验收、依赖显式。回到 1.2 的选型标准——能切能验才上框架，这三个范式都满足，所以跑得稳。反观那些"一个角色包打天下"的伪多智能体，往往只是把单链路换皮，没拿到协作红利。 一个落地建议：别一上来抄完整范式。先用三角色（检索/撰写/核查）跑通最小闭环，验证链路与成本，再按业务痛点加角色——比如发现核查总漏，才加独立核查角色；发现取数慢，才把取数拆出来并行。每次加角色都有收益对照，系统才不会胖。 ## 收尾提醒：案例的价值不是"照抄结 收尾提醒：案例的价值不是"照抄结构"，而是"对照自己的业务形状，判断该不该切、怎么切"。本章前三站（集成、社区、案例）都是在帮你建立"该往哪拼、该信谁、该学哪样"的判断力。下一站路线图，给这个判断加一个时间维度：框架在变，你的投入怎么不贬值。 <!-- qc_expand_409_v1 --> ## 拆解三个真实落地形态 光讲能力太空，下面把 CrewAI 落到三种常见业务形态，看角色怎么分、Task 怎么链、价值在哪。 案例一：投研简报生成。研究员 Agent 检索→写手 Agent 成稿→合规 Agent 审核（human_input）。价值是把一天的人工压缩到十分钟，且每篇都过同一道合规闸。 案例二：客服工单分诊。分类 Agent 判意图→检索 Agent 找知识库→回复 Agent 起草→质检 Agent 把关。价值是高峰时段不堆单，且回复口径统一。 案例三：代码评审助手。静态分析 Agent 找坏味道→安全 Agent 查漏洞→总结 Agent 出评审意见。价值是把三类专家意见并到一封评审里。 ⚠️ 常见坑：案例一里把合规审核也设成全自动，对外口径一旦出错就是品牌事故。高风险输出必须留 human_input，机器只起草、人拍板。 researcher = Agent(role="研究员", goal="检索事实", backstory="严谨", verbose=True) writer = Agent(role="写手", goal="成稿", backstory="清楚", verbose=True) compliance = Agent(role="合规", goal="把关", backstory="谨慎", verbose=True) t1 = Task(description="检索 {topic} 事实", expected_output="事实清单", agent=researcher) t2 = Task(description="写成简报", expected_output="简报", agent=writer, context=[t1]) t3 = Task(description="合规审核简报", expected_output="通过/驳回", agent=compliance, context=[t2], human_input=True) # 高风险节点留人 crew = Crew(agents=[researcher, writer, compliance], tasks=[t1, t2, t3], process=Process.sequential) print("投研简报 Crew 组装完成, 含人工闸门:", t3.human_input)
💡 关键直觉：好的落地案例都有一个共同结构——把"人类专家团队的分工"翻译成"Agent 的角色分工"。你不是在发明新工作流，而是在用更便宜、更不知疲倦的"数字员工"复刻一套已被验证的协作，并在高风险处保留真人。
# 多案例共用同一套角色模板，只是 Task 不同 roles = ["研究员", "写手", "合规"] agents = [Agent(role=r, goal="g", backstory="b", verbose=True) for r in roles] print(len(agents), "个角色就位")