这次我们来看一个关于大模型 Agent 技能拆解的技术话题。如果你正在开发或使用基于 LLM 的智能体，一定遇到过这种情况：同一个 Agent 技能，有时能精准完成任务，有时却直接“翻车”，输出完全错误或陷入死循环。这背后的原因是什么？是提示词写得不好，还是模型能力不足，或是框架设计有缺陷？

本文不空谈概念，而是从一篇经典的 Agent 论文解读入手，结合当前主流的 Agent 开发框架（如 LangChain、AutoGen 等）的实践经验，深入拆解 LLM Agent 技能的核心构成、执行链路以及那些导致“翻车”的关键因素。我们会重点关注技能的设计模式、工具调用（Tool Calling）的稳定性、上下文（Context）管理策略，以及如何通过工程化手段提升 Agent 的可靠性。

对于开发者而言，读完本文你将能清晰地诊断 Agent 技能失效的原因，并掌握一套从技能设计、提示工程到错误处理的最佳实践，从而构建出更稳定、更可控的智能体应用。

1. 核心能力速览：理解 Agent 技能的本质

在深入“翻车”原因前，我们先明确 LLM Agent 技能是什么。它不是一个魔法黑盒，而是一个由多个组件精密协作的“微服务”。

能力项 说明与拆解
技能定义 一个可被 Agent 调用的具体功能单元，通常包含：功能描述、输入参数规范、执行逻辑（代码或 API 调用）、输出格式。
核心组件 1. 意图识别 ：LLM 理解用户指令，判断是否需要调用此技能。
2. 参数提取 ：从指令或上下文中提取技能执行所需的参数。
3. 工具执行 ：调用外部工具（代码解释器、API、数据库等）。
4. 结果解析与响应 ：处理工具返回的结果，并生成面向用户的自然语言回答。
常见形式 - 单一工具调用 ：如“查询天气”、“计算数学公式”。
- 工作流（Workflow） ：多个工具按顺序或条件组合，如“先爬取数据，再进行分析，最后生成报告”。
- 规划与执行循环 ：Agent 自主规划步骤，并循环调用工具直至任务完成。
“翻车”高发区 意图识别错误、参数提取偏差、工具执行异常、上下文遗忘或污染、无限循环。
调试复杂度 中高。需要观察 LLM 的中间推理过程、工具调用的输入输出，并对长上下文进行管理。

简单来说，一个技能是否“好用”，取决于上述每个环节是否都能稳定、准确地运行。任何一个环节的微小偏差，都可能导致最终结果的彻底失败。

2. 适用场景与使用边界

LLM Agent 技能并非万能。明确其边界是避免“翻车”的第一步。

适合场景：

  1. 结构化任务自动化 ：任务目标明确，输入输出格式相对固定，如数据查询、格式转换、内容摘要。
  2. 增强模型能力 ：弥补大模型在实时信息、精确计算、专业领域知识等方面的不足，如联网搜索、代码执行、专业数据库查询。
  3. 复杂工作流编排 ：将多个简单技能组合，完成一个多步骤的复杂任务，如竞品分析报告生成、自动化测试脚本编写。

不适合场景：

  1. 完全开放式的创意生成 ：如“写一部小说”，这更依赖模型本身的生成能力，工具调用帮助有限。
  2. 需要极高精确性和确定性的任务 ：如金融交易、医疗诊断。Agent 的决策过程存在不可预测性。
  3. 实时性要求极高的交互 ：工具调用和 LLM 推理会引入延迟。

合规与安全边界：

  • 工具权限 ：必须严格限制技能可访问的工具和 API 权限，遵循最小权限原则。特别是涉及文件系统、网络请求、数据库操作的技能。
  • 内容安全 ：对技能生成的内容需建立审核机制，防止生成有害、偏见或侵权信息。
  • 数据隐私 ：技能处理用户数据时，必须确保符合数据保护法规，避免敏感信息泄露。

3. 环境准备与前置条件

分析 Agent 技能不需要特定的 GPU 或大型模型部署环境，但需要一个可以运行和调试 Agent 框架的 Python 开发环境。

基础环境：

  • 操作系统 ：Windows 10/11, macOS, Linux (Ubuntu 推荐) 均可。
  • Python 版本 ：Python 3.8 及以上。
  • 包管理工具 ： pip 或 conda 。

核心依赖（以 LangChain 为例）： 你需要安装主流的 Agent 开发框架和对应的 LLM 接入库。以下是一个基础的 requirements.txt 示例： 

# 核心Agent框架
langchain>=0.1.0
langchain-community
# OpenAI API (或其他模型API，如智谱、DeepSeek)
openai>=1.0.0
# 用于定义和调用工具
langchain-experimental
# 用于可视化Agent执行过程（调试神器）
langchain-visualizer
# 其他可能用到的工具库
requests
python-dotenv

LLM 接入准备：

  • 云端 API ：你需要一个可用的 LLM API 密钥（如 OpenAI GPT-4/3.5-Turbo， Anthropic Claude， 国内大模型平台等）。这是 Agent 的“大脑”。
  • 本地模型 ：如果你想完全本地化，可以使用 ollama 部署本地模型（如 Llama 3, Qwen2）并通过 langchain-ollama 集成。但这会牺牲一定的响应速度和能力。

关键概念准备： 在编码前，请确保理解以下概念，它们是拆解技能的基础：

  • 提示词模板（PromptTemplate） ：如何构造引导 LLM 思考和决策的指令。
  • 链（Chain） ：LangChain 中将组件组合在一起的基础单元。
  • 工具（Tool） ：一个可调用的函数，是技能的具体实现。
  • 代理（Agent） ：负责决策（选择工具）和执行循环的控制器。

4. 技能设计模式与代码实现

“翻车”往往源于糟糕的技能设计。我们来看几种常见的设计模式及其潜在风险点。

4.1 基础工具调用模式

这是最简单的技能，Agent 根据用户指令调用一个工具。 

from langchain.agents import initialize_agent, Tool
from langchain.agents import AgentType
from langchain_openai import ChatOpenAI
import math

# 1. 定义工具函数
def calculate_power(base: float, exponent: float) -> str:
    """计算一个数的幂。输入应为 base 和 exponent 两个数字。"""
    try:
        result = math.pow(base, exponent)
        return f"{base}^{exponent} = {result}"
    except Exception as e:
        return f"计算出错: {e}"

# 2. 包装成LangChain Tool对象
tools = [
    Tool(
        name="PowerCalculator",
        func=calculate_power,
        description="用于计算幂运算。输入应该是两个用逗号分隔的数字，例如 '2,3' 表示计算2的3次方。"
    )
]

# 3. 初始化LLM和Agent
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, # 一种经典的Agent类型
    verbose=True # 开启详细日志，方便调试！
)

# 4. 运行测试
result = agent.run("请计算 5 的平方是多少？")
print(result)

潜在“翻车”点：

  • 描述不清 ： description 字段模糊，导致 LLM 无法正确匹配工具。
  • 参数解析错误 ：用户说“5的平方”，LLM 需要正确解析出 base=5, exponent=2 ，并格式化成 5,2 传入。如果解析逻辑复杂，极易出错。
  • 错误处理不足 ：工具函数内没有良好的异常捕获和返回，导致 Agent 收到意外输出而困惑。

4.2 多步骤工作流模式

技能本身是一个包含多个子步骤的链条。 

from langchain.chains import LLMChain, SimpleSequentialChain
from langchain.prompts import PromptTemplate

# 假设我们有两个简单的文本处理技能
# 技能1：生成摘要
summary_template = """请为以下文本生成一个简洁的摘要：
文本：{text}
摘要："""
summary_prompt = PromptTemplate(input_variables=["text"], template=summary_template)
summary_chain = LLMChain(llm=llm, prompt=summary_prompt)

# 技能2：翻译成英文
translate_template = """将以下中文文本翻译成英文：
中文：{text}
英文："""
translate_prompt = PromptTemplate(input_variables=["text"], template=translate_template)
translate_chain = LLMChain(llm=llm, prompt=translate_prompt)

# 组合成顺序工作流：先摘要，后翻译
overall_chain = SimpleSequentialChain(chains=[summary_chain, translate_chain], verbose=True)

# 执行
input_text = "大语言模型智能体（LLM Agent）是当前人工智能领域的重要方向，它通过结合大语言模型的推理能力和外部工具的执行能力，来完成复杂任务。"
result = overall_chain.run(input_text)
print(result)

潜在“翻车”点：

  • 链式错误传播 ：第一步摘要如果跑偏（例如提取了无关信息），那么错误的摘要会被送入第二步翻译，最终结果必然错误。
  • 上下文丢失 ： SimpleSequentialChain 默认只传递上一个链的输出作为下一个链的输入。如果后续步骤需要原始输入或更早的中间结果，需要更复杂的链结构（如 SequentialChain ）。
  • 缺乏状态检查 ：没有在步骤间加入验证逻辑。例如，摘要是否过短？翻译后是否保留了原意？

4.3 带有条件判断的规划-执行模式

这是最强大也最容易“翻车”的模式。Agent 需要动态规划步骤。 

from langchain.agents import initialize_agent, Tool
from langchain.agents import AgentType
from langchain_community.utilities import SerpAPIWrapper
from langchain_community.tools import YouTubeSearchTool

# 定义多个工具
search = SerpAPIWrapper()
yt_search = YouTubeSearchTool()

tools = [
    Tool(
        name="Web Search",
        func=search.run,
        description="当你需要回答关于当前事件或获取最新信息时使用。输入是一个具体的搜索查询。"
    ),
    Tool(
        name="YouTube Search",
        func=yt_search.run,
        description="当用户想查找视频内容时使用。输入是一个视频主题关键词。"
    ),
]

llm = ChatOpenAI(model="gpt-4", temperature=0) # 复杂任务建议使用更强模型
agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION, # 支持结构化输出的Agent
    verbose=True,
    handle_parsing_errors=True # 重要：处理输出解析错误
)

# 执行一个需要规划的任务
result = agent.run("我想学习如何用Python进行机器学习，请先帮我看看最新的趋势文章，再找一个入门教学视频。")

潜在“翻车”点（高发！）：

  • 规划幻觉 ：LLM 可能规划出不合理或无法执行的步骤序列。
  • 循环陷阱 ：Agent 在两个工具间反复横跳，无法达成终止条件（例如，搜索“最佳结果”，不满意，再搜索“更佳结果”，陷入死循环）。
  • 上下文爆炸 ：多轮工具调用和结果会不断追加到上下文，可能超过模型窗口限制，导致遗忘早期关键信息。
  • 输出解析失败 ：Agent 的输出可能不符合框架预期的结构化格式（如 JSON），导致 handle_parsing_errors 被触发，任务中断。

5. 功能测试与效果验证：构建你的“翻车”测试集

不要等到生产环境才发现问题。为你的 Agent 技能设计针对性的测试用例。

5.1 基础功能测试

验证技能在理想输入下的表现。

  • 测试用例1（精准匹配） ：输入“计算2的10次方”，预期 Agent 调用计算器工具并返回“1024”。
  • 测试用例2（自然语言变体） ：输入“帮我算一下一百除以二十五等于多少”，预期 Agent 能理解并调用计算工具，返回“4”。
  • 判定标准 ：是否调用了正确的工具？参数提取是否准确？最终答案是否正确？

5.2 边界与异常测试

这是发现“翻车”的主要手段。

  • 测试用例3（模糊指令） ：输入“算个数”。预期：Agent 应追问“请问您要计算什么？”，而不是随意猜测一个工具。
  • 测试用例4（工具能力外） ：输入“预测明天的股票价格”。预期：如果 Agent 没有股票预测工具，它应回答“我无法完成股票预测”，而不是尝试调用不相关的搜索工具给出误导信息。
  • 测试用例5（复杂参数） ：输入“帮我找找去年关于AI Agent的论文，要PDF格式的”。预期：Agent 需要理解“去年”（时间参数）、“AI Agent”（主题参数）、“PDF”（格式参数）。很可能提取失败或调用错误的搜索API。
  • 判定标准 ：Agent 是否表现出合理的“自知之明”？是否进行了不当的工具调用？是否给出了误导性回复？

5.3 多轮对话与状态测试

验证技能在持续对话中的稳定性。

  • 测试流程 ：
    1. 用户：“今天的北京天气怎么样？”（Agent 应调用天气查询工具）。
    2. 用户：“那上海呢？”（Agent 应能理解“上海”指代“上海的天气”，并再次调用工具，且不应混淆两地信息）。
    3. 用户：“我刚刚问的第一个城市是哪里？”（测试 Agent 的对话历史记忆能力）。
  • 判定标准 ：Agent 是否能正确维护对话上下文？指代消解是否准确？是否会因为历史信息过多而性能下降或出错？

5.4 长文本与复杂工作流测试

针对工作流类技能。

  • 测试用例 ：输入一篇长技术文章，要求“请总结其核心观点，并列出文中提到的所有工具名称，最后评估这篇文章的难度等级”。
  • 判定标准 ：
    • 摘要技能 ：是否抓住了核心，而非复制开头段落？
    • 信息提取技能 ：是否完整列出了所有工具，没有遗漏或虚构？
    • 评估技能 ：评估标准是否一致、合理？
    • 整体流程 ：三个子任务是否按正确顺序执行？中间结果传递是否正确？

6. 接口 API 与批量任务处理

当技能稳定后，你需要将其封装为服务或处理批量任务。

6.1 将 Agent 技能封装为 API 服务

使用 FastAPI 可以快速将你的 Agent 技能暴露为 HTTP 接口。 

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from your_agent_module import your_agent_executor # 导入你写好的Agent执行器

app = FastAPI(title="LLM Agent Skill API")

class AgentRequest(BaseModel):
    query: str
    session_id: str = None # 用于维护会话状态
    max_steps: int = 10 # 防止无限循环

class AgentResponse(BaseModel):
    session_id: str
    answer: str
    tool_calls: list = [] # 记录调用了哪些工具，用于审计和调试
    status: str # “success”, “error”, “max_steps_exceeded”

@app.post("/v1/ask", response_model=AgentResponse)
async def ask_agent(request: AgentRequest):
    """处理用户查询的端点"""
    try:
        # 这里应包含会话管理逻辑，根据 session_id 获取历史上下文
        result, tool_logs = await your_agent_executor.arun(
            query=request.query,
            session_id=request.session_id,
            max_steps=request.max_steps
        )
        return AgentResponse(
            session_id=request.session_id or generate_new_session_id(),
            answer=result,
            tool_calls=tool_logs,
            status="success"
        )
    except MaxStepsExceededError:
        raise HTTPException(status_code=400, detail="Agent exceeded maximum reasoning steps.")
    except Exception as e:
        # 记录详细日志，但返回给用户的信息要友好
        logger.error(f"Agent execution failed: {e}")
        raise HTTPException(status_code=500, detail="An internal error occurred.")

# 客户端调用示例 (curl)
# curl -X POST "http://localhost:8000/v1/ask" \
# -H "Content-Type: application/json" \
# -d '{"query": "计算圆周率的前5位", "session_id": "user123"}'

API 化关键点：

  • 会话管理 ：通过 session_id 维护对话状态，避免每次请求都是全新的对话。
  • 步骤限制 ： max_steps 是防止 Agent 陷入无限循环的 安全阀 ，必须设置。
  • 错误隔离 ：Agent 内部的错误不应导致整个 API 崩溃，要有全局异常捕获和友好错误返回。
  • 审计日志 ：记录每次请求的 tool_calls ，对于排查“翻车”原因至关重要。

6.2 批量任务处理

如果需要用同一个技能处理大量数据（如批量总结100篇文档），直接循环调用 Agent 效率低下且成本高。

优化策略：

  1. 任务分解与并行 ：将批量输入拆分成独立任务，利用线程池或异步任务队列（如 Celery）并行处理。
  2. 上下文隔离 ：确保每个任务有独立的上下文，避免交叉污染。
  3. 简化 Agent ：对于批量任务，往往不需要复杂的规划和多轮对话。可以设计一个“简化版”技能，固定工具调用流程，减少 LLM 的决策点。
  4. 缓存与去重 ：如果批量任务中有相似输入，可以考虑对中间结果（如工具调用结果）进行缓存。 
import asyncio
from concurrent.futures import ThreadPoolExecutor
from your_agent_module import simple_summarize_agent # 一个专用于摘要的简化Agent

def process_batch_documents(doc_list: list[str], max_workers: int = 5):
    """使用线程池批量处理文档摘要"""
    summaries = []
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        # 提交任务
        future_to_doc = {executor.submit(simple_summarize_agent, doc): doc for doc in doc_list}
        for future in asyncio.as_completed(future_to_doc):
            doc = future_to_doc[future]
            try:
                summary = future.result(timeout=60) # 设置超时
                summaries.append((doc[:50], summary)) # 存储摘要
            except Exception as exc:
                logger.error(f"Document processing failed for {doc[:50]}: {exc}")
                summaries.append((doc[:50], "Processing Error"))
    return summaries

7. 资源占用与性能观察

Agent 的性能瓶颈主要不在 GPU 显存，而在 API 调用成本、延迟和上下文长度。

1. Token 消耗与成本观察：

  • 主要消耗点 ：用户提问、系统提示词、工具描述、历史对话、工具执行结果、Agent 的思考过程（如 ReAct 格式中的 Thought: 部分）。
  • 优化方法 ：
    • 精简工具描述 ：在保证清晰的前提下，用最少的单词描述工具功能。
    • 压缩历史上下文 ：使用 ConversationSummaryBufferMemory 或 ConversationTokenBufferMemory 等记忆组件，自动摘要或截断历史对话。
    • 选择性包含工具结果 ：如果工具返回了大段 JSON 或文本，考虑让 Agent 先提取关键信息再放入上下文。

2. 延迟分析：

  • 链路拆解 ：Agent 响应时间 = LLM 生成时间 + 工具执行时间 + 网络延迟（如果调用外部 API）。
  • ** profiling 工具**：使用 langchain.callbacks 中的回调函数来记录每个步骤的耗时。 
    from langchain.callbacks import StdOutCallbackHandler
handler = StdOutCallbackHandler()
agent.run("查询天气", callbacks=[handler]) # 会在控制台输出详细的时间日志
  • 优化方向 ：对于慢速工具，考虑异步调用或设置超时；对于复杂任务，评估是否值得使用更慢但更强的模型（如 GPT-4）。

3. 成功率与稳定性监控：

  • 定义指标 ：任务完成率、工具调用准确率、平均对话轮数、异常退出率。
  • 实现监控 ：在代码关键节点（工具调用前/后、最终输出前）埋点，记录日志到监控系统（如 Prometheus + Grafana）。
  • 典型监控项 ：
    • agent_tool_call_total ：工具调用次数。
    • agent_tool_call_error_total ：工具调用失败次数。
    • agent_max_steps_exceeded_total ：达到最大步数限制的任务数。

8. 常见“翻车”原因与排查方法

当你发现 Agent 技能失效时，可以按照下表进行排查。

问题现象 可能原因 排查方式 解决方案
Agent 完全不理睬指令，直接闲聊 1. 系统提示词（System Prompt）太弱或缺失。
2. 工具描述（Tool Description）不清晰，Agent 无法匹配。
3. 使用的 Agent 类型（如 CHAT_CONVERSATIONAL_REACT_DESCRIPTION ）不适合当前任务。 		1. 检查初始化 Agent 时传入的 system_message 。
2. 将 verbose=True ，观察 Agent 的思考过程（ Thought: ），看它是否在尝试理解工具。
3. 尝试更换更简单的 Agent 类型，如 ZERO_SHOT_REACT_DESCRIPTION 。 		1. 强化系统提示词，明确指令：“你是一个助手，必须使用工具来回答问题。”
2. 重写工具描述，使其更精准、更具区分度。
3. 根据任务复杂度选择合适的 Agent 类型。
调用了错误工具 1. 工具描述相似度太高。
2. 用户指令存在歧义。
3. LLM 的意图识别能力不足。 		1. 查看 verbose 日志，看 Agent 选择工具时的理由（ Action: 和 Action Input: ）。
2. 测试不同的指令表达方式。 		1. 差异化工具描述，强调每个工具的独特用途。
2. 在系统提示词中增加工具选择规则。
3. 使用 StructuredTool 提供更严格的参数模式，或使用 OpenAIFunctionsAgent 等利用模型原生函数调用能力的 Agent。
参数提取错误 1. 用户指令中的参数格式复杂。
2. 工具期望的输入格式与 LLM 解析出的格式不匹配。 		1. 查看 Action Input 的值是否正确。
2. 在工具函数入口打印接收到的参数。 		1. 在工具描述中明确指定输入格式，例如：“输入必须是‘城市名’的格式”。
2. 在 Agent 和工具之间增加一个参数校验和格式化的中间层。
3. 使用 Pydantic 模型来定义工具输入，利用 LLM 的结构化输出能力。
陷入无限循环 1. 任务无法完成，Agent 不断重试。
2. 工具返回的结果让 Agent 认为需要再次调用工具。
3. 缺少明确的终止条件。 		1. 观察日志，看循环调用的工具和参数是否相同。
2. 检查工具返回的结果是否包含错误或模糊信息。 		必须设置 max_iterations 或 max_execution_time 参数！
1. 优化工具设计，确保其在失败时返回明确、可操作的错误信息。
2. 在系统提示词中增加循环避免指令，如“如果第一次尝试失败，请分析原因并尝试另一种方法，不要简单重复。”
上下文过长导致遗忘或性能下降 1. 多轮对话历史积累。
2. 工具返回了过长的内容（如大段网页文本）。 		1. 监控每次请求消耗的 Token 数。
2. 观察后期对话中 Agent 是否提及早期信息。 		1. 使用 ConversationSummaryBufferMemory 自动压缩历史。
2. 在工具层面进行结果过滤和摘要，只将关键信息返回给 Agent。
3. 定期清空或重置会话。
输出解析失败 Agent 的回复不符合框架预期的解析格式（如 JSON 格式错误）。 查看报错信息，通常是 OutputParserException 。 1. 启用 handle_parsing_errors=True 参数，让 Agent 有机会重试。
2. 简化输出格式要求。
3. 使用更强大的模型（如 GPT-4）来生成更规范的结构化输出。

9. 最佳实践与使用建议

基于以上分析，要打造一个“不翻车”或“少翻车”的 Agent 技能，请遵循以下工程化实践：

1. 设计阶段：

  • 单一职责 ：每个技能应专注于完成一件明确的事情。功能越复杂，失败点越多。
  • 描述即契约 ：工具的名称和描述是 LLM 理解它的唯一途径，务必清晰、准确、无歧义。
  • 防御性编程 ：在工具函数内部进行严格的输入验证和异常处理，返回对 Agent 友好的错误信息。

2. 提示工程阶段：

  • 强引导系统提示词 ：明确告诉 Agent 它的角色、可用工具、调用规则以及最重要的——何时应该停止。
  • 提供少量示例（Few-Shot） ：在提示词中提供 1-2 个正确调用工具的示例，能极大提升模型表现。
  • 设定边界 ：在提示词中说明工具的局限性，例如“你无法预测未来事件”。

3. 开发与测试阶段：

  • 始终开启 Verbose 模式 ：在开发调试期，这是你洞察 Agent“内心想法”的最重要窗口。
  • 构建测试集 ：包含正常用例、边界用例和异常用例。自动化测试是保障技能迭代不倒退的关键。
  • 实施分级降级 ：对于关键技能，准备一个简化版或后备方案。当主技能连续失败时，可以自动降级。

4. 部署与运维阶段：

  • 设置硬性限制 ： max_iterations （最大迭代次数）和 max_execution_time （最大执行时间）是必须配置的安全网。
  • 全面日志记录 ：记录完整的决策链（Thought, Action, Observation），这是事后分析“翻车”现场的唯一依据。
  • 监控与告警 ：对错误率、循环次数、平均响应时间等关键指标进行监控，并设置告警阈值。

LLM Agent 技能的开发是一个持续迭代和优化的过程。没有一劳永逸的提示词或设计。每一次“翻车”都是一个宝贵的调试机会，通过分析日志、优化提示、改进工具设计，你能逐渐构建出真正鲁棒、可信的智能体应用。建议从最简单的技能开始，逐步增加复杂度，并在每个阶段进行充分测试。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区