问题根源常是分工错误而非提示词不足；需先通过日志检查输入干净度、输出是否符合字段契约、错误类型分布，再针对性合并职责、切割模糊地带或增设衔接岗，并用结构化schema和可验证指令替代主观要求。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy多Agent流程跑出来结果和预期偏差大，比如调研Agent交回一堆网页快照却没提炼要点、写作Agent把数据表格硬塞进段落里破坏可读性、校验Agent只检查错别字却漏掉逻辑矛盾——这时候你盯着日志反复看，第一反应常是“提示词是不是写得不够狠”，但真正卡住进度的，往往不是要求没说清，而是分工本身就把人和活儿配错了。
先判断问题出在“谁该干啥”还是“要干成啥样”
打开WorkBuddy工作台→进入该Workflow详情页→点击「执行历史」→找到最近一次失败或低质输出的运行记录→点开每个Agent的独立日志。重点看三处：【输入内容是否干净】（比如写作Agent收到的是否只有结构化要点，还是混着原始HTML和调试日志）、【输出是否符合本环节定义目标】（调研Agent的输出字段契约里是否明确写了“必须返回带来源标注的3条核心结论”，而不是“整理资料”这种模糊描述）、【错误类型是否集中在某类动作】（全是格式错误？全是事实遗漏？还是上下游交接时字段名对不上？）。如果三个Agent的输入都含冗余信息、输出都偏离字段契约、错误类型分散，说明分工设计有硬伤；如果只有写作Agent输出混乱，其他环节正常，才值得回头重写它的提示词和Skill调用逻辑。
改分工：当角色边界被现实任务顶穿了
方法一：合并重叠职责
比如你设了“数据采集Agent”和“清洗Agent”，但实际运行中发现采集Agent总在拉取时就做过滤，清洗Agent反而无事可做，还因等待超时被跳过——这说明采集环节已隐含清洗动作，强行拆分会制造空转。直接删掉清洗Agent，把清洗规则写进采集Agent的Skill配置里，用正则+字段白名单双控输入质量。
方法二：切割模糊地带
若“分析Agent”产出的结果常被“报告Agent”大幅重写，翻日志发现分析Agent输出里夹杂了大量解释性语句（如“因为用户反馈集中于加载慢，所以建议优先优化API响应”），而报告Agent的任务本应是组织语言而非做归因——这就是角色越界。立刻修改分析Agent的系统提示词，在开头加一句：“你只输出结构化结论，不提供推理过程；所有‘因为…所以…’句式由报告Agent生成”。同时在Workflow编排中，把分析Agent的输出字段从text改为json，强制它只填{“root_cause”: “API响应延迟”, “evidence”: [“Jira-123”, “Sentry-456”]}这类键值对。
方法三：补上缺失的衔接岗
常见断点是调研Agent交出原始URL列表，写作Agent却无法解析页面内容——它没配网页阅读Skill，也不该配。这时不该让写作Agent去学爬虫，而要插入一个专职的“内容提取Agent”，它唯一任务就是接收URL列表→调用ReadWebPage Skill→返回纯文本摘要+关键数据表格。这个Agent不参与观点输出，只做信息保真搬运。它的存在，让前后两个Agent彻底解耦。
改要求：当分工合理但指令失焦
第一步：锁定具体Agent的提示词入口
在WorkBuddy控制台左侧导航栏点击「Skills & Agents」→找到对应Agent名称→点击右侧「编辑」图标→切换到「System Prompt」标签页。
第二步：删掉所有形容词和立场词
把“请专业、严谨、全面地分析用户反馈”改成“从Jira导出的CSV中提取字段：issue_id、priority、description；对description做关键词聚类（阈值0.6），输出TOP3聚类标签及各自覆盖issue数”。模型不理解“专业”，但能执行“字段提取+聚类+计数”。每一条要求必须可验证、可回溯、不依赖主观判断。
第三步：用字段契约锁死输入输出
在该Agent的「Input Schema」中，明确定义必填字段：{“source_csv_url”: “string”, “min_priority”: “number”}；在「Output Schema」中，强制约束返回格式为JSON，且必须包含key：“clusters”（array of object）、“total_issues”（number）。WorkBuddy会在运行前自动校验结构，不满足直接报错中断，避免下游拿到半成品瞎猜。
验证改动是否生效
① 在Workflow编辑页，点击右上角「测试运行」→上传一份最小化测试数据（比如仅含3条Jira记录的CSV）→观察各Agent日志中输入/输出是否严格匹配新契约；
② 故意传入错误格式数据（如把CSV换成PDF链接），确认系统是否在第一个Agent就触发Schema校验失败并抛出明确错误码，而不是让错误流到下游再崩溃；
③ 连续三次成功运行后，打开「监控面板」→查看该Workflow的「平均端到端耗时」和「单Agent失败率」，若前者下降15%以上且后者归零，则本次调整完成。
