2026年，AI办公工具已从“对话式交互”演进到“代理式执行”阶段。但“能做”与“稳定交付”之间存在显著的系统工程差距。

本文选取WorkBuddy、AiPy、TRAE Work、Kimi Work四款产品，在PPT生成、会议纪要、数据分析三个真实任务场景中进行架构层拆解与执行能力实测，评估其技术路线差异与适用边界。

一、测试方法论与产品架构定位

1.1 评估框架

本次实测从三个维度评估每款产品：

• 执行范式：任务拆解与工具调用的系统架构

• 能力边界：预置能力 vs 动态扩展的覆盖范围

• 交付质量：输出结构化程度与误差率

1.2 产品技术路线定位

产品	核心架构	执行范式	能力扩展机制
WorkBuddy	生态调度层（腾讯Harness）	ReAct循环+工具调用（MCP协议）	预置Skill+Connector注册
AiPy	Python代码执行引擎	动态代码生成+自我修正闭环	Python生态20万+第三方库
TRAE Work	Code/Work双模式切换	模态感知+云端执行	预置Skill+云端智能体
Kimi Work	Agent集群编排器	多Agent并行+WebBridge	子Agent动态扩缩（上限300）

二、PPT生成：速度基线、信息深度与视觉渲染的工程权衡

2.1 任务定义

输入：一份包含行业动态、公司公告、投融资事件的结构化文本（约5000字）。输出：10页左右的行业周报PPT。

2.2 执行架构对比

WorkBuddy（总耗时≈5分10秒）：采用“知识检索→信息整合→幻灯片生成→视觉渲染”四阶段流水线。关键参数：Temperature=0.3（降低创造性偏差），Token预算≈8000。实测信息密度高，引用了真实数据源。在SuperCLUE三次测试中波动系数最低（CV=0.04），输出一致性最优。

但数据溯源存在系统性偏差：在一次行业周报任务中，WorkBuddy将“未检索到公开动态”误判为“事件未发生”，将乐聚机器人与它石智航的IPO与MIT TR35入选事件漏报。这是一个典型的召回率与精确率权衡问题：系统为控制幻觉（Hallucination）提升了精确率，但牺牲了召回率。

TRAE Work（总耗时≈4分30秒）：速度最快的产品，采用云端预置Builder管线，推理请求直接路由到预计算资源池。在“跳一跳”小游戏生成任务中耗时5分钟即交付完整HTML文件。但信息深度不足：行业周报任务中大量引用了内容聚合平台链接而非一手数据源，信息图层的原始性（Data Provenance）存在衰减。

Kimi Work（总耗时≈用户定义）：采用“长文本解析→信息抽取→逻辑大纲生成→视觉渲染”的分离式管线。实测中分析师用300页市场调研报告生成15页汇报PPT，耗时从3小时缩至30分钟，内容完整度提升40%。

但视觉渲染能力存在系统性短板：图文错位、页边距过窄、多维数据无法生成图表（降级为文字描述）。根本原因在于Kimi Work缺乏专门的视觉排版引擎，采用了“语义模板填充”而非“布局约束求解”。

AiPy（总耗时≈任务复杂度线性增长）：不提供现成PPT模板。采用“需求描述→Python代码生成→数据整理→markdown转PPT”的执行链路。用户在首轮设置中需描述数据源、汇总维度、图表类型等参数。首次配置约15-20分钟，但可固化为Script Assets，后续执行可自动化。

2.3 PPT生成结论

指标	WorkBuddy	TRAE Work	Kimi Work	AiPy
速度	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐（首轮）
信息深度	⭐⭐⭐（数据溯源偏差）	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
视觉渲染	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐（需用户定义）
稳定性	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
可扩展性	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐

三、会议纪要：上下文理解与结构化输出的精度边界

3.1 任务定义

输入：一段45分钟会议录音（约12000字转写文本）+3份背景材料（PDF，约80页）。输出：正式会议纪要（含决议事项、待办任务与责任人标注）。

3.2 执行能力对比

WorkBuddy：在结构化输出上表现稳定——会议主题、参会人、核心决议、待办事项格式工整。在腾讯文档中实现了人机双写协同，AI生成内容与人工修改在同一文档空间内并行，采用操作变换（OT）算法解决冲突同步。

但创意分析能力是系统性短板：在实测创意策划任务中打分仅两星（满分五星），逻辑推理偶尔出现前后矛盾（数据结论与文本结论偏离）。根本原因在于上下文窗口（Context Window）限制：长会议纪要生成时，早期信息被压缩或截断，导致“遗忘”现象。

Kimi Work：长上下文理解是核心竞争力。实测中将45页年报PDF丢入，30秒输出包含“财务摘要-业务分析-风险提示-投资展望”的完整结构。关键区别在于上下文窗口管理策略：Kimi Work采用分层摘要（Hierarchical Summarization），将早期信息沉淀为高层特征后保留在上下文中，而非直接丢弃。

TRAE Work：在会议纪要任务上表现中规中矩。它对输入材料的结构敏感度较高：输入结构化程度高的文本（如已分点记录的会议要点）输出质量显著优于原始转写文本。缺乏针对非结构化长文本的专门优化。

AiPy：会议纪要不是它的典型场景。可配置为“录音转文字→关键词提取→分类归档”的自动化脚本管线，但需要用户预先定义纪要模板和分类规则，不适合一次性、无预设的临时任务。

3.3 会议纪要结论

WorkBuddy在结构化输出和人机协同上最优，但在长上下文一致性上有窗口限制。Kimi Work在长文本信息抽取上能力最强，但交付格式（长文本+摘要）更适合研究笔记而非正式会议纪要。TRAE Work依赖输入材料的预结构化程度。AiPy适合已定义规则的固定流程化纪要，不适合即兴任务。

四、数据分析：执行精确度、自动化深度与误差控制

4.1 任务定义

输入：包含2025年某行业全量数据（多格式混合：CSV、JSON、Excel），要求输出各维度汇总统计与数据口径理解。

4.2 执行能力对比

WorkBuddy：速度最快，但精确度存在系统性偏差。在行业销量数据统计中，交付速度第一，但数据偏差明显——比亚迪批发数据错误，未能区分“销量”与“批发”两个不同口径。根本原因在于其基于LLM的信息抽取对数据口径的语义消歧能力不足。

Kimi Work：同任务中数据完全准确，正确识别了“销量”而非“批发”，交付的Word和Excel排版清晰。关键差异在于Kimi Work在做数值统计时采用了更结构化的数据校验策略（可能涉及规则引擎叠加）。

AiPy：在这个场景的架构优势最大。采用“需求描述→pandas代码生成→本地执行→交付结果”的闭环。数据清洗、格式统一、批量处理、异常值检测都可精确编码为Python逻辑。实测中22万行混乱数据从输入到输出仅需10分钟，误差边界由pandas逻辑定义而非LLM推理。

TRAE Work：优势在于混合场景——如果分析过程中需要处理代码相关子任务（如从特定格式日志中提取字段），可在Work和Code之间无缝切换，无需更换工具。

4.3 数据分析结论

指标	WorkBuddy	Kimi Work	AiPy	TRAE Work
执行速度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐（首轮配置）	⭐⭐⭐⭐
精确度	⭐⭐（口径理解偏差）	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
数据清洗能力	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
可编程扩展	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
混合任务处理	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

五、系统性结论：四款产品的技术适应边界

WorkBuddy：生态调度型Agent，适合“高频、低熵、固定流程”的日常办公任务（周报、会议纪要初稿）。优势在速度和稳定性，短板在深度推理与精确数据提取，需人工复核关键结论。

Kimi Work：长上下文Agent，适合“高信息密度、长文档、研究导向”的知识工作（研报、文献综述、信息收集）。优势在上下文理解和信息整合，短板在视觉渲染和图表生成，不适合需要强视觉输出的任务。

AiPy：代码执行型Agent，适合“结构化、重复性、安全敏感”的数据处理任务（批量清洗、定时报表、自动化脚本）。优势在精确控制和可扩展性，短板在即时即兴任务，需首轮配置成本。

TRAE Work：混合模态Agent，适合“办公+开发交叉”的混合场景（产品原型、技术报告、数据分析中的代码处理）。优势在场景切换的低成本，短板在单一场景深度不及专精工具。

四款产品的本质差异不在“谁更强”，而在“谁在哪个任务上的工程优化做得最透”。选型的关键不是选功能最全的，而是选功能最贴你高频场景的。