Posts

软件测试的AI革命 传统软件测试面临三个困境：测试用例编写耗时、回归测试成本随代码增长线性上升、边界条件难以穷举。AI正在从根本上改变测试的经济学——从"人写测试"到"AI生成测试"。 测试用例生成 基于代码的单元测试生成 class UnitTestGenerator: def __init__(self, llm): self.llm = llm def generate_tests(self, source_code, framework="pytest"): # 1. 分析源代码 analysis = self._analyze_code(source_code) # 2. 生成测试策略 strategy = self._generate_strategy(analysis) # 3. 生成测试用例 test_cases = [] for test_scenario in strategy: test = self.llm.generate(f""" 为以下函数生成测试用例： 函数代码： {source_code} 测试场景：{test_scenario} 框架：{framework} 要求： - 使用有意义的测试名称 - 包含Arrange-Act-Assert结构 - 覆盖正常路径和异常路径 - 使用参数化测试减少重复 """) test_cases.append(test) # 4. 验证测试可运行 validated = self._validate_tests(test_cases, source_code) return validated def _analyze_code(self, code): """分析代码结构和依赖""" return { "functions": extract_functions(code), "classes": extract_classes(code), "dependencies": extract_imports(code), "complexity": compute_complexity(code), "branches": extract_branches(code), } def _generate_strategy(self, analysis): """基于代码分析生成测试策略""" scenarios = [] for func in analysis["functions"]: scenarios.extend([ f"测试 {func.name} 的正常输入", f"测试 {func.name} 的边界值", f"测试 {func.name} 的异常输入", f"测试 {func.name} 的空值处理", ]) # 复杂函数需要更多测试 if func.complexity > 10: scenarios.append(f"测试 {func.name} 的复杂分支组合") return scenarios 基于API规范的集成测试 class APITestGenerator: def __init__(self, llm): self.llm = llm def generate_from_openapi(self, spec): """从OpenAPI规范生成测试""" tests = [] for endpoint in spec["paths"]: for method in spec["paths"][endpoint]: operation = spec["paths"][endpoint][method] # 生成正常请求测试 tests.append(self._generate_happy_path(endpoint, method, operation)) # 生成参数边界测试 tests.extend(self._generate_boundary_tests(endpoint, method, operation)) # 生成认证授权测试 tests.extend(self._generate_auth_tests(endpoint, method, operation)) # 生成并发测试 if method in ["POST", "PUT", "DELETE"]: tests.append(self._generate_concurrency_test(endpoint, method)) return tests def _generate_boundary_tests(self, endpoint, method, operation): """生成边界值测试""" tests = [] for param in operation.get("parameters", []): if param["in"] == "query": schema = param.get("schema", {}) if schema.get("type") == "integer": tests.append({ "name": f"测试 {param['name']} 最小值", "request": {param["name"]: schema.get("minimum", 0)} }) tests.append({ "name": f"测试 {param['name']} 最大值", "request": {param["name"]: schema.get("maximum", 999999)} }) tests.append({ "name": f"测试 {param['name']} 超范围", "request": {param["name"]: schema.get("maximum", 999999) + 1}, "expected_status": 400 }) return tests 智能回归测试 测试选择 代码变更后不需要运行所有测试，AI可以预测哪些测试可能受影响： ...

上下文窗口：模型的"工作台" 上下文窗口是模型的工作台——它能在一次推理中处理的所有信息。窗口越大，模型能"看到"的信息越多，但也意味着更高的计算成本和更慢的推理速度。如何在有限的窗口中放入最有价值的信息，是一个核心工程问题。 窗口大小的演进 GPT-3 (2020): 2K tokens GPT-3.5 (2022): 4K-16K tokens GPT-4 (2023): 8K-128K tokens Gemini 1.5 (2024): 1M-2M tokens Llama 4 (2026): 256K-10M tokens 窗口在持续增长，但"能用"和"用好"是两回事。研究表明，即使支持百万token的窗口，模型在长上下文中的表现也远不如短上下文——这就是"Lost in the Middle"问题。 Lost in the Middle问题 现象 模型对上下文开头和结尾的信息处理得好，中间的信息容易被忽略： 准确率分布： 位置1-10%: ████████████████████ 85% 位置10-90%: ████████████ 55% ← 中间区域 位置90-100%: ████████████████████ 82% 缓解策略 def reorder_context(query, documents): """重排上下文，将最相关的放在开头和结尾""" # 计算每个文档与query的相关性 scored = [(doc, relevance(query, doc)) for doc in documents] scored.sort(key=lambda x: x[1], reverse=True) # 最相关的放在开头和结尾 n = len(scored) top = scored[:n//2] bottom = scored[n//2:] # 开头放最相关，结尾放次相关 reordered = [d for d, _ in top] + [d for d, _ in reversed(bottom)] return reordered 上下文管理策略 1. 滑动窗口 最简单的策略：保留最近的N条消息，丢弃更早的： class SlidingWindow: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens self.messages = [] def add(self, message): self.messages.append(message) self._truncate() def _truncate(self): while self._total_tokens() > self.max_tokens: self.messages.pop(0) # 移除最早的消息 问题：完全丢失早期上下文，可能遗忘关键信息。 ...

从工具到平台：AI的操作系统化 传统操作系统管理硬件资源、提供系统调用、运行应用程序。AI操作系统（AI-OS）将这一范式升级：用大模型作为"内核"，用自然语言作为"系统调用"，用Agent作为"应用程序"。这不是科幻——多个团队已在构建雏形。 AI-OS的架构愿景 分层架构 ┌──────────────────────────────────────────┐ │ 用户交互层 │ │ (自然语言 / 多模态 / 脑机接口) │ ├──────────────────────────────────────────┤ │ Agent运行时层 │ │ (Agent调度 / 隔离 / 权限 / 通信) │ ├──────────────────────────────────────────┤ │ LLM内核层 │ │ (推理 / 规划 / 记忆 / 对齐) │ ├──────────────────────────────────────────┤ │ 工具与API层 │ │ (MCP Server / 函数调用 / 外部服务) │ ├──────────────────────────────────────────┤ │ 数据与知识层 │ │ (向量DB / 知识图谱 / 文件系统) │ ├──────────────────────────────────────────┤ │ 硬件抽象层 │ │ (GPU/NPU调度 / 存储 / 网络) │ └──────────────────────────────────────────┘ LLM内核 传统OS内核负责进程调度、内存管理、文件系统。AI-OS的LLM内核负责： ...

推理时计算：大模型能力提升的新维度 传统提升模型能力的方式是"训练时计算扩展"——更多参数、更多数据、更多训练算力。OpenAI o1开创了"推理时计算扩展"——在推理阶段投入更多计算来获得更好的输出。这就像人类的System 2思维：花更多时间思考，得到更准确的答案。 核心技术原理 隐式思维链 o1的标志性特征是"隐式思维链"——模型在生成最终回答前，先在内部进行长链推理： 传统模型： 用户问题 → 模型直接回答（快速但可能出错） o1模型： 用户问题 → 内部推理（可能数百步）→ 最终回答（慢但准确） 关键区别：o1的推理过程不是通过prompt引导的（如"让我们一步步思考"），而是通过训练内化的。模型学会了在生成答案前先"思考"。 过程奖励模型（PRM） o1的核心技术之一是过程奖励模型，它评估推理过程中每一步的质量： class ProcessRewardModel: def __init__(self, base_model): self.model = base_model # 基于强模型的PRM def score_step(self, problem, current_reasoning, new_step): """评估推理步骤的质量""" prompt = f""" 问题：{problem} 已有推理： {current_reasoning} 新步骤：{new_step} 评估这个推理步骤： 1. 正确性（1-10）：这一步的推理是否正确 2. 相关性（1-10）：这一步是否与解决问题相关 3. 进展性（1-10）：这一步是否推进了解题 输出JSON。 """ result = self.model.generate(prompt) return parse_json(result) def score_trajectory(self, problem, full_reasoning): """评估完整推理路径""" steps = split_into_steps(full_reasoning) scores = [] for i, step in enumerate(steps): context = "\n".join(steps[:i]) score = self.score_step(problem, context, step) scores.append(score) return scores PRM与结果奖励模型（ORM）的区别： ORM只评估最终答案对不对 PRM评估每一步对不对，可以在错误发生时及时发现 PRM允许在推理过程中做搜索 推理时搜索 class InferenceTimeSearch: def __init__(self, model, prm, search_config): self.model = model self.prm = prm self.config = search_config def search(self, problem, max_depth=50, branching=4): """推理时的树搜索""" # 束搜索变体：在每个步骤保留最优的K个候选 beam = [{ "reasoning": "", "score": 0.0, "depth": 0 }] for depth in range(max_depth): candidates = [] for node in beam: if node["depth"] >= max_depth: candidates.append(node) continue # 生成多个候选步骤 steps = self.model.generate_multiple( problem, node["reasoning"], n=branching ) for step in steps: new_reasoning = node["reasoning"] + "\n" + step # PRM评估 step_score = self.prm.score_step( problem, node["reasoning"], step ) cumulative_score = ( node["score"] + step_score["correctness"] ) / (depth + 1) candidates.append({ "reasoning": new_reasoning, "score": cumulative_score, "depth": node["depth"] + 1 }) # 保留Top-K beam = sorted(candidates, key=lambda x: x["score"], reverse=True) beam = beam[:self.config["beam_width"]] # 检查是否找到答案 best = beam[0] if self._has_answer(best["reasoning"]): return self._extract_answer(best["reasoning"]) return self._extract_answer(beam[0]["reasoning"]) 训练方法推测 推理数据生成 o1需要大量高质量的推理数据来训练。这些数据可能来自： ...

AutoGen：对话驱动的多Agent框架 微软研究院的AutoGen开创了"对话即协作"的Agent范式。与LangGraph的图驱动不同，AutoGen将多Agent协作建模为一组Agent之间的对话，每个Agent有独立的角色和能力。 核心架构 Agent类型体系 from autogen import ( ConversableAgent, AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager ) # AssistantAgent: AI助手，有系统消息定义角色 researcher = AssistantAgent( name="Researcher", system_message="""你是一位AI研究分析师。 职责： 1. 分析用户需求 2. 搜索和整理相关信息 3. 提供结构化的分析报告 约束： - 基于事实，不编造 - 注明信息来源 - 区分事实和推测 """, llm_config={"model": "gpt-4o", "temperature": 0.3}, tools=[web_search, knowledge_base_search] ) # UserProxyAgent: 用户代理，可以执行代码 user_proxy = UserProxyAgent( name="User", human_input_mode="NEVER", # 不等待人类输入 code_execution_config={ "work_dir": "workspace", "use_docker": True, # 安全执行环境 "timeout": 60 } ) 对话管理 class ConversationManager: def __init__(self): self.conversations = {} self.termination_conditions = [] def add_termination(self, condition): """添加对话终止条件""" self.termination_conditions.append(condition) def check_termination(self, messages): for condition in self.termination_conditions: if condition.check(messages): return True return False # 常见终止条件 class MaxRoundsTermination: def __init__(self, max_rounds=10): self.max_rounds = max_rounds def check(self, messages): return len(messages) >= self.max_rounds class KeywordTermination: def __init__(self, keywords): self.keywords = keywords def check(self, messages): if messages: return any(kw in messages[-1]["content"] for kw in self.keywords) return False 多Agent协作模式 模式1：顺序对话 def sequential_conversation(task): """Agent按顺序处理任务""" # Agent 1: 分析需求 analysis = analyst.generate(f"分析以下任务：{task}") # Agent 2: 编写代码 code = coder.generate(f"基于以下分析编写代码：{analysis}") # Agent 3: 审查代码 review = reviewer.generate(f"审查以下代码：{code}") # Agent 4: 优化代码 if "问题" in review: final_code = coder.generate(f"根据审查意见优化代码：{review}") else: final_code = code return final_code 模式2：群聊协作 def group_chat_collaboration(task): """多Agent群聊协作""" agents = [ UserProxyAgent(name="User", human_input_mode="NEVER"), AssistantAgent(name="Planner", system_message="负责制定计划"), AssistantAgent(name="Coder", system_message="负责编写代码"), AssistantAgent(name="Tester", system_message="负责测试"), AssistantAgent(name="Reviewer", system_message="负责审查") ] group_chat = GroupChat( agents=agents, messages=[], max_round=20, speaker_selection_method="auto" # 自动选择下一个发言者 ) manager = GroupChatManager( groupchat=group_chat, llm_config={"model": "gpt-4o"} ) agents[0].initiate_chat(manager, message=task) 模式3：嵌套对话 def nested_conversation(task): """Agent内部发起子对话""" # 主Agent处理任务 main_agent = AssistantAgent( name="Main", system_message="你是项目经理，可以委托子任务给其他Agent" ) # 当主Agent遇到需要深入研究的子问题时 # 它可以发起一个子对话 def research_subtask(subtask): researcher = AssistantAgent( name="Researcher", system_message="你是研究员，擅长信息检索" ) result = researcher.generate(f"研究：{subtask}") return result # 主Agent可以在处理过程中调用子对话 main_agent.register_function( function_map={"research": research_subtask} ) 代码执行环境 安全执行 class SafeCodeExecutor: def __init__(self): self.docker_config = { "image": "python:3.11-slim", "timeout": 60, "memory_limit": "512m", "cpu_limit": 1.0, "network": "none", # 禁止网络访问 } self.allowed_packages = [ "numpy", "pandas", "matplotlib", "scipy", "scikit-learn" ] def execute(self, code): # 1. 静态检查 issues = self._static_check(code) if issues: return {"error": "代码检查未通过", "issues": issues} # 2. Docker执行 result = self._docker_exec(code) return result def _static_check(self, code): """静态安全检查""" forbidden = [ "import os", "import subprocess", "import socket", "open(", "__import__", "eval(", "exec(" ] issues = [] for pattern in forbidden: if pattern in code: issues.append(f"禁止使用: {pattern}") return issues 代码执行反馈循环 def code_feedback_loop(agent, task, max_attempts=3): """代码编写-执行-修正的反馈循环""" for attempt in range(max_attempts): # Agent生成代码 code = agent.generate(f"任务：{task}\n尝试：{attempt+1}") # 执行代码 result = executor.execute(code) if result["success"]: return code, result["output"] # 反馈错误，让Agent修正 feedback = f""" 代码执行失败： 错误信息：{result['error']} 请修正代码。 """ task = task + "\n\n" + feedback return None, "达到最大尝试次数" 高级特性 Agent可序列化 def save_agent_state(agent, path): """保存Agent状态，支持恢复""" state = { "name": agent.name, "system_message": agent.system_message, "llm_config": agent.llm_config, "chat_history": agent.chat_messages, "registered_tools": list(agent.tools.keys()) } with open(path, 'w') as f: json.dump(state, f) def load_agent_state(path): """从文件恢复Agent""" with open(path) as f: state = json.load(f) agent = AssistantAgent( name=state["name"], system_message=state["system_message"], llm_config=state["llm_config"] ) agent.chat_messages = state["chat_history"] return agent 自定义Agent行为 class CustomAgent(ConversableAgent): def __init__(self, name, **kwargs): super().__init__(name, **kwargs) self.register_hook("process_message_before_send", self._preprocess) self.register_hook("process_message_after_receive", self._postprocess) def _preprocess(self, message): """发送前预处理""" # 添加时间戳 message["content"] = f"[{datetime.now()}] {message['content']}" return message def _postprocess(self, message): """接收后处理""" # 记录消息日志 self._log(message) return message def _log(self, message): """消息日志""" with open("agent_log.jsonl", 'a') as f: f.write(json.dumps({ "timestamp": datetime.now().isoformat(), "sender": message.get("from"), "content": message["content"][:200] }) + "\n") 实际案例：数据分析Agent def build_data_analysis_agent(): """构建数据分析Agent系统""" # 数据科学家Agent data_scientist = AssistantAgent( name="DataScientist", system_message="""你是数据科学家，负责： 1. 理解用户的数据分析需求 2. 编写Python代码进行数据分析 3. 解释分析结果 使用pandas, numpy, matplotlib进行数据分析。 确保代码包含异常处理和数据验证。 """, llm_config={"model": "gpt-4o"} ) # 代码执行Agent code_runner = UserProxyAgent( name="CodeRunner", human_input_mode="NEVER", code_execution_config={ "work_dir": "analysis_workspace", "use_docker": "python:3.11-slim" }, system_message="你负责执行代码并返回结果。不生成代码，只执行。" ) # 启动分析 code_runner.initiate_chat( data_scientist, message="""分析销售数据： 1. 读取 /data/sales.csv 2. 按月统计销售趋势 3. 找出Top 10产品 4. 生成可视化图表 5. 输出分析报告 """ ) AutoGen vs 其他框架 维度 AutoGen LangGraph CrewAI 核心范式 对话驱动 图驱动 角色驱动 代码执行 内置Docker 需自定义 需自定义 多Agent 原生支持 需手动编排 支持 状态管理 对话历史 检查点 任务上下文 适合场景 研究探索 生产系统 快速原型 结语 AutoGen将多Agent协作还原为最自然的形式——对话。它的优势在于代码执行能力和灵活的对话管理。劣势在于控制精度不如图驱动框架。对于需要多专家协作探索的研究型任务，AutoGen是最佳选择。对于需要精确控制执行流程的生产系统，LangGraph更合适。选择框架的关键是匹配你的任务特性。 ...

数据：大模型能力的源头 “Garbage in, garbage out"在LLM时代被放大了1000倍。一个7B模型用高质量数据训练可以超越用低质量数据训练的70B模型。数据治理是决定模型能力上限的第一道关卡。 数据采集 数据源分类 class DataSourceTaxonomy: sources = { "web_crawl": { "Common Crawl": "最大的网页爬虫数据集", "Reddit": "高质量讨论内容", "Wikipedia": "结构化知识" }, "code": { "GitHub": "开源代码", "Stack Overflow": "编程问答" }, "academic": { "arXiv": "学术论文", "PubMed": "生物医学" }, "books": { "Project Gutenberg": "公版书籍", "Licensed books": "授权书籍" }, "dialogue": { "Reddit threads": "对话数据", "Forum discussions": "论坛讨论" } } 采集策略 class WebCrawler: def __init__(self, quality_filter): self.filter = quality_filter def crawl(self, url): # 1. 抓取页面 html = self._fetch(url) # 2. 正文提取（去除导航、广告等） content = self._extract_main_content(html) # 3. 质量初筛 quality_score = self.filter.assess(content) if quality_score < 0.3: return None # 质量太低，跳过 # 4. 语言检测 lang = detect_language(content) # 5. 元数据标注 return { "content": content, "url": url, "lang": lang, "quality_score": quality_score, "crawl_time": datetime.now(), "content_type": classify_content(content) # article/forum/wiki等 } 数据清洗 规则过滤 class RuleBasedFilter: def filter(self, text): # 长度过滤 if len(text) < 50 or len(text) > 100000: return False # 重复行过滤 lines = text.split('\n') unique_ratio = len(set(lines)) / len(lines) if unique_ratio < 0.5: return False # 特殊字符比例 special_ratio = sum(1 for c in text if not c.isalnum() and c not in ' \n.,!?;:\'"-()') / len(text) if special_ratio > 0.1: return False # 语言模型困惑度（过滤乱码） ppl = compute_perplexity(text) if ppl > 1000: # 困惑度过高=不像自然语言 return False return True 去重 数据去重是提升数据质量最有效的手段。研究表明，去重可以将模型性能提升3-5个点。 ...

AI音乐：从MIDI到端到端生成的飞跃 AI音乐生成经历了三个阶段：符号生成（MIDI）、波形生成（WaveNet）、端到端歌曲生成（Suno/Udio）。2026年的AI音乐已经可以生成包含人声、伴奏、混音的完整歌曲，质量接近专业制作水准。 技术路线对比 符号生成：MIDI时代 早期的AI音乐生成在符号空间操作——生成MIDI音符序列： class MIDIGenerator: def __init__(self, model): self.model = model # Transformer模型 def generate(self, prompt, length=500, temperature=1.0): # MIDI表示为事件序列 # Note On, Note Off, Velocity, Time Shift events = [SOS_TOKEN] for _ in range(length): logits = self.model(events) next_event = sample(logits, temperature) events.append(next_event) if next_event == EOS_TOKEN: break # 转换为MIDI return events_to_midi(events) 符号生成的优势：完全可控（可以精确编辑每个音符），文件小，生成快。 劣势：不包含音色、混音、人声等音频层面的信息，听起来像电子琴。 音频生成：扩散模型 直接在波形或频谱空间生成音频： class AudioDiffusionModel: def __init__(self, unet, scheduler): self.unet = unet # U-Net去噪网络 self.scheduler = scheduler # 噪声调度器 def generate(self, conditioning, duration=10.0, sr=44100): # 计算潜在空间形状 latent_length = int(duration * sr / self.vae_hop_length) # 从纯噪声开始 latent = torch.randn(1, self.latent_dim, latent_length) # 迭代去噪 for t in reversed(range(self.scheduler.num_steps)): # 预测噪声 noise_pred = self.unet(latent, t, conditioning) # 去噪一步 latent = self.scheduler.step(latent, noise_pred, t) # 解码为音频 audio = self.vae.decode(latent) return audio 端到端歌曲生成 Suno和Udio代表了端到端歌曲生成的最高水平。它们的架构大致如下： ...

企业AI Agent：从Demo到生产的鸿沟 很多企业在Demo阶段看到AI Agent的惊艳表现就急于推广，但在生产环境中遇到准确性、可靠性、成本等一系列问题。本文基于多个企业级AI Agent项目的实战经验，梳理从场景选择到ROI评估的完整方法论。 场景选择框架 适合Agent化的任务特征 class TaskSuitabilityScorer: def score(self, task): return { "repetitiveness": self._score_repetitiveness(task), # 重复性 "rule_complexity": self._score_rule_complexity(task), # 规则复杂度 "data_dependency": self._score_data_dependency(task), # 数据依赖度 "error_tolerance": self._score_error_tolerance(task), # 容错度 "value_per_action": self._score_value(task), # 单次价值 } def recommend(self, scores): total = sum(scores.values()) if total > 15: # 满分25 return "推荐Agent化" elif total > 10: return "需进一步评估" else: return "暂不建议" 推荐的首批场景 高价值低风险场景（推荐首批落地）： 内部知识问答：基于企业文档的RAG系统 容错度高（答错可以纠正） 价值明确（减少重复问询） 数据可控（内部文档） 代码审查辅助：自动化代码review 人机协作（AI初审，人终审） 标准明确（编码规范） ROI可量化（减少审查时间） 客服工单分类与路由：自动分类和派发 任务边界清晰 错误可纠正 量大利好明显 暂不建议的场景： 直接面向客户的金融建议 医疗诊断 法律判决参考 自动执行资金操作 技术架构设计 分层架构 ┌─────────────────────────────────┐ │ 用户交互层 │ │ (Web/移动端/API) │ ├─────────────────────────────────┤ │ Agent编排层 │ │ (意图理解 → 规划 → 执行) │ ├─────────────────────────────────┤ │ 能力层 │ │ (RAG | 工具调用 | 代码生成) │ ├─────────────────────────────────┤ │ 模型层 │ │ (LLM | Embedding | Reranker) │ ├─────────────────────────────────┤ │ 数据层 │ │ (向量DB | 知识图谱 | 文档库) │ ├─────────────────────────────────┤ │ 基础设施层 │ │ (GPU集群 | 监控 | 日志) │ └─────────────────────────────────┘ 关键设计决策 模型选择： ...

AIGC检测的现实困境 随着AI生成内容质量逼近人类写作，区分AI和人类内容变得越来越难。检测技术与生成技术的军备竞赛正在加速——而检测方天然处于劣势。 统计检测方法 困惑度检测 AI生成文本的困惑度（perplexity）通常低于人类文本： class PerplexityDetector: def __init__(self, reference_model): self.model = reference_model def detect(self, text): # 计算困惑度 ppl = self._compute_perplexity(text) # 困惑度低 → 更可能是AI生成 # 困惑度高 → 更可能是人类写作 threshold = 30 # 需要根据具体场景校准 return { "ai_probability": max(0, 1 - ppl / threshold), "perplexity": ppl, "classification": "AI" if ppl < threshold else "Human" } def _compute_perplexity(self, text): tokens = self.model.tokenize(text) log_prob = self.model.compute_log_prob(tokens) return math.exp(-log_prob / len(tokens)) 局限：经过轻微改写（同义词替换、句式调整）就可以大幅提高困惑度，绕过检测。 Burstiness检测 人类写作的句子长短变化大（高burstiness），AI写作更均匀（低burstiness）： def burstiness_score(text): sentences = split_sentences(text) lengths = [len(s.split()) for s in sentences] mean_len = np.mean(lengths) std_len = np.std(lengths) # 变异系数 cv = std_len / mean_len # 人类通常CV > 0.5，AI通常 < 0.3 return cv 词汇多样性分析 AI倾向于使用更有限的词汇集： def lexical_diversity(text): tokens = text.lower().split() unique = set(tokens) # Type-Token Ratio ttr = len(unique) / len(tokens) # Yule's K（更鲁棒的多样性指标） k = compute_yules_k(tokens) return {"ttr": ttr, "yules_k": k} 水印技术 文本水印：绿色token法 在生成过程中对token选择施加统计偏移，留下不可见水印： ...

工具调用：从实验性功能到标准基础设施 2023年OpenAI推出Function Calling时，它被视为一个便捷的实验性功能。到2026年，工具调用已成为大模型应用的标准基础设施——每个Agent都需要调用工具，而调用方式的标准化程度直接决定了开发效率。 各厂商方案对比 OpenAI Function Calling OpenAI的方案是最早的标准化工具调用格式： { "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, "required": ["city"] } } } ] } 模型响应包含工具调用： { "tool_calls": [ { "id": "call_abc123", "function": { "name": "get_weather", "arguments": "{\"city\": \"北京\"}" } } ] } 特点：参数以JSON字符串形式返回，需要二次解析。Parallel function calling支持一次调用多个工具。 Anthropic Tool Use Anthropic的格式与OpenAI类似但在细节上有差异： { "tools": [ { "name": "get_weather", "description": "获取指定城市的天气", "input_schema": { "type": "object", "properties": { "city": {"type": "string"} }, "required": ["city"] } } ] } 差异点： 用input_schema替代parameters 参数直接作为对象返回，不需要二次解析 工具调用结果用tool_result消息类型返回 Google Gemini Function Calling { "function_declarations": [ { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string"} } } } ] } 差异点：用function_declarations替代tools，响应格式也略有不同。 ...