工具与技术

精读 Anthropic Financial Services 一、进入项目：四层目录，各司其职 Anthropic 在 GitHub 上发布了一个叫 financial-services 的项目，随后出现了不少介绍它的文章，标题大多是"Anthropic 开源了金融 AI Agent"“10 个金融角色全覆盖"之类。但仔细看那些介绍，大多数停在截图和目录层面——这个项目有哪些文件夹，大概能做什么，就到此为止了。 这篇文章想做两件更具体的事：一是搞清楚这个项目里面到底有什么、怎么用；二是从它的文件里提炼出可以直接借鉴的方法——如果你有自己的专业工作流，怎么把它固化成像这个项目一样的 Skill 文件。 先把项目结构说清楚。整个 repo 有四个顶层目录： p m c s l a l c u a v p n a r g g e a a u i i e r r g d p n n t t e e t s t i n d - s / - c e - f p a r a l l - g r u - b e - g p u n m i l i t s n u l - f s g t c t / i / o - n o 3 s k 6 / b 5 o - o i k n s s / t a l l / 1 7 2 同 将 部 0 一 署 个 个 批 C 和 个 垂 合 插 l 校 金 直 作 件 a 验 融 领 伙 的 u 脚 工 域 伴 d 本 作 的 插 A e 流 技 件 P 插 能 （ I 部 件 和 L 署 命 S 部 到 令 E 署 企 库 G 模 业 、 板 S M & 3 P 6 5 G l 的 o b I a T l ） 安 装 工 具 根目录下的 .claude-plugin/marketplace.json 是整个 repo 的"目录页”，把所有可独立安装的插件（20 个）列在一起，作为一个 marketplace 源发布。 ...

GitHub 上有个新项目，2天斩获2万 star。 作者 Santiago 在找工作时，用它评估了 516 个岗位、生成了 631 份报告、最终投递 68 份，拿到了 Head of Applied AI 的 offer。 它吸引我的不只是结果，而是背后的两件事：他对求职流程的系统化思考，以及他用 Claude Code 构建多智能体协作的方式。 求职的系统化思考 找工作包含大量的重复劳动 Santiago 的核心洞察很朴素：求职中 70% 的工作是重复的分析劳动，而不是决策。读岗位描述、映射自己的技能、判断匹配度、改简历、填表单，这些动作每个岗位都要重复一遍。 他的数据也验证了这一点：631 份评估报告中，74% 的 offer 得分低于 4.0（满分 5.0）。也就是说，如果没有系统化筛选，大量时间会花在根本不合适的机会上。 评估框架先于行动 他设计了一套 10 维加权评分体系，其中角色匹配和技能匹配是最关键的指标——不匹配直接 pass。其余维度包括资历、薪酬、公司阶段等。 这个框架的价值在于：把"什么是好机会"从直觉判断，变成了可执行的结构化标准。 简历是论证，不是文档 他不是拿着一份简历到处投，而是基于每个岗位动态生成简历：从岗位描述中提取 15-20 个关键词，识别岗位属于 6 个工作方向中的哪一个，然后按相关性重排经历的优先级制。 ...

我们需要怎样的多 agent 最近我看到了一个十分有趣的多 agent 项目——三省六部制，首先用户是皇上，不论怎么讲，先过一把登基的瘾。它任命了一个太子，专门负责消息的分拣分发，平时和你闲聊，需要的时候就给下面派任务。下面有三省（中书·门下·尚书）：负责需求规划，质量品控，任务调度。 最后还有执行六部（现在加了一个早朝官，变七部了），分别执行代码编写、bug 修复、数据处理，对任务进行了细致的划分，一个部门掌握一小摊。 先不管效果怎么样，如果早朝的时候，所有agent都先说一遍吾皇万岁万岁万万岁，那这个系统还是提供情绪价值的。相关的帖子下面，最有趣的评论莫过于，这套系统最大的问题就是容易导致token爆炸，国库空虚🤣。 在这个有趣的开源项目之外，我开始思考一个问题：人类的分工套用在agent上是不是合适的？ 人类为什么进行分工 亚当·斯密在《国富论》开篇第一章便是论分工，他开宗明义地提到：劳动生产力最大的进步都是分工的结果。在亚当·斯密观察大头针工厂时，他发现当一个人试图完成所有工序，其效率远远低于一群各司其职的专人。当一个人专心完成一个工序时，经验的增长，判断力的提高，都进一步地提高生产力。 因此，当人类让 agent 深度参与自己的工作时，第一个想到的就是将全链条的工作进行切分。以市场调研为例，很多人设计的多 agent 工作流会包括：调研员（收集信息）、分析师（整理洞察）、策略师（给建议）、文案（写提案）——因为在正常人类社会中，这些本就由不同工种各自完成。 这个直觉很自然。但 AI 的"分工"，真的和人类的分工是一回事吗？ AI 分工面临的独特问题 拆分越多，丢失越多 人类分工时，交接的是信息——一份文件、一个结论、一条指令。但 AI 在完成任务的过程中，积累的不只是信息，还有感知：在收集素材过程中形成的判断、在反复尝试中建立的路径感知。这些东西很难打包交接。 还是以市场调研为例。调研员 agent 在收集信息的过程中，会注意到某个数据的异常、某个用户反馈的微妙差异——这些构成了它对这个市场的"感知"。但当它把一份调研报告交给下一个分析师 agent 时，报告里有数据，没有这些感知。分析师拿到的是结论，不是过程；是表格，不是直觉。当一个多 agent 流水线把任务拆开，上一个节点往往只将最终产出交给下一个节点，而上下文信息在交接中被稀释掉了。拆得越细，丢失的越多。 上下文够大之后 多 agent 架构最初流行，有一个很实际的工程原因：早期模型的上下文窗口很小，一个 agent 根本装不下一条完整链路所需的信息，只能拆开来各管一段。 但现在的模型，上下文窗口已经足够大，能力也足够强，一个 agent 完全可以从头到尾完成整条链路上的工作。那些因为"装不下"而拆分的理由，正在逐渐失效。 不过，上下文边界并没有消失，只是变得更隐蔽。当 agent 发现自己接近上下文边界，它甚至会开始"恐慌"——着急把任务结束，以免撞上限制。OpenClaw 创始人 Peter Steinberger 在采访中提到，他会跟 agent 说"take it slow，慢慢来"。如果不这么说，agent 会在 thinking 里念叨"哦，我的上下文快接近上限了，所以我需要……“然后仓皇收尾。“慢慢来”，成了他工作流里神奇的提示词工程的一部分。 角色隔离是值得主动设计的 当然，有一种拆分是值得的：构建者与评估者的分离。 agent 在完成自己的任务之后，往往会自信地说"我干得不错”。这时候，就需要另一个带有空白上下文的 agent 来审视它——由于没有过去构建时的路径依赖，它更容易发现问题，也更容易提出结构化的意见。 这不是模拟人类的"质检部门"，而是利用了 AI 的一个特性：全新的上下文，意味着全新的眼光。 专家实践：Peter 的「轻管理」方案 我不想泛泛地讨论理论。Anthropic、LangChain 的博客里有很多类似的分析，最近关于 Harness Engineering 的讨论也受到了关注。让我们看看真正在用多 agent 工作流做出现象级应用的人是怎么做的。 ...