如何构建在你睡觉时寻找商机的智能体图

如何构建一个在你睡觉时替你发现商业机会的 Agent Graph July 24, 2026 · 14 min read · View source ↗ Marketing Automation 大多数机会研究死于疲惫。 你决定去研究点东西——一个市场、一个利基、一类交易。你在第一个候选对象上花了四个小时。你拉数据、算数学、核约束，结论是它很平庸。然后你看着清单上剩下的十一个候选对象，悄悄停了下来。不是因为方法错了，而是因为四个小时乘以十二，等于为了几个结论搭上一整周的工作量，而你还有一份工作。 能找到好机会的人，很少是更聪明的分析师。他们只是能过完更多的候选对象。产量就是全部的优势，而产量恰恰是手动研究流程无法产出的东西。 这篇文章构建一个能产出产量的系统。不是一个 agent 在一个循环里苦磨，而是一张由专业化 agent 组成的小型图：一个负责扫描，一个负责分析，一个负责验证，外加一条只在你值得注意的候选对象出现时才唤醒你的路由规则。它整夜运行。到了早上，你读到的是一份简短的结论清单，而不是一长串"你也许该去看看"的东西。 在开始构建之前有一个警告，因为它塑造了下面的一切：大多数任务并不需要一张图。一个范围清晰的单一 agent 配上一个好的验证器，就是一个循环；当一个循环就够用时却去搭一张图，会把一个两小时的任务变成一个两天的框架项目。这个特定任务配得上一张图，而下一节之后会解释确切原因，这样你就能把同样的测试应用到你接下来要构建的任何东西上。 为什么这个任务配得上一张图 一个循环就是一张单节点图，带着一条回到自身的边。你所知道的关于循环设计的一切——发现-计划-执行-验证的周期、停止条件、验证器——都是一个节点的内部。当几个循环需要彼此交接时，你得到的就是一张图，而图工程（graph engineering）就是决定它们如何连接的学科。 所以问题从来不是"图还是循环"。而是"这项工作是否拆分成彼此交接的、真正不同的专长"。对于机会扫描而言，答案是的，有四点。 工作拆分成真正的专长。找候选对象是一个广度任务：广撒网、松过滤、产出一份清单。分析一个候选对象是一个深度任务：拉具体数字、跑公式、产出一个结论。验证一份分析是一个持怀疑态度的任务：核查输入、追捕那个让交易作废的细节、试图杀死这笔交易。那是三个不同的岗位，有三套不同的成功标准；把它们塞进一个 agent 的循环里，意味着那个发现了有前景候选对象的 agent，同时也是那个判断它是否有前景的 agent。 它需要扇出和扇入。一次扫描产出十几个候选对象。逐个顺序分析它们，会浪费本可免费获得的并行能力。把分析扇出到各个候选对象上，再把结果扇回到一张排序好的清单里。 失败需要隔离。一个数据破损或缺失的候选对象应该自己失败并被标记，而不是破坏整次运行，也不是污染其他所有东西的排名。 验证必须独立。这是决定性的一条。一个产出了某份分析的 agent，是那份分析最糟糕的评判者，因为它共享了它刚刚做出的每一个假设。在几乎任何 agent 图里，价值最高的节点，几乎总是一个独立的、只读的验证器，它唯一的工作就是核查另一个节点的工作。 四个触发条件，全部命中。这才是结构成立的依据。如果你的任务只命中其中一个，那就去搭循环。 架构 这张图有四个节点、五条边，以及一个沿着它们传递的共享状态对象。 ┌─────────────────┐ schedule ─────►│ SCANNER │ │ finds candidates│ └────────┬────────┘ │ state: {criteria, candidates[]} │ ┌────┴────┐ fan-out ▼ ▼ ▼ ┌─────────────────┐ │ ANALYZER │ (one per candidate, │ scores + math │ running in parallel) └────────┬────────┘ └────┬────┘ fan-in │ state: {..., analyses[] with verdicts} │ ▼ ┌─────────────────┐ │ VERIFIER │ │ tries to kill it│ └────────┬────────┘ │ state: {..., confirmed[], rejected[]} │ verdict == STRONG? │ ┌─────────────┴─────────────┐ yes no │ │ ▼ ▼ ┌─────────────┐ ┌──────────────┐ │ BRIEF │ │ ARCHIVE │ │ wakes you │ │ silent log │ └─────────────┘ └──────────────┘ 四个节点。底部那条条件边，是让这套系统变得宜居的东西，因为它区分了一份你会读的报告和一份你会忽略的报告。所有不是 STRONG 的东西都进入一个你可以查阅、但永远不必去读的归档。 共享状态 状态是把一堆 agent 变成一套系统、而不是一个忘光一切群聊的东西。在写任何一个节点之前，先显式定义它，因为状态漂移（state drift）是图腐坏最常见的方式。 STATE OBJECT (travels along every edge): { "run_id": "...", "run_date": "...", "criteria": { "domain": "what kind of opportunity", "hard_filters": ["non-negotiable constraints"], "thresholds": {"strong": "...", "marginal": "...", "skip": "..."} }, "candidates": [ {"id": "...", "name": "...", "raw_data": {...}, "source": "..."} ], "analyses": [ {"candidate_id": "...", "numbers": {...}, "score": 0.0, "verdict": "STRONG | MARGINAL | SKIP", "reasoning": "...", "assumptions": ["what this verdict depends on"]} ], "verifications": [ {"candidate_id": "...", "status": "CONFIRMED | REJECTED | UNCERTAIN", "failed_checks": [...], "reason": "..."} ], "errors": [ {"candidate_id": "...", "node": "...", "error": "..."} ] } 里面有两个设计决策值得点出来。 每份分析上的 assumptions 字段之所以存在，是为了让验证器有具体的东西可以攻击。一份不陈述自己假设了什么的分析，是无法被有意义地核查的，因为验证器在测试它之前，必须先重建那份推理。 errors 数组是用来隔离失败的东西。一个在分析过程中崩溃的候选对象会写下一个错误并退出。它不会让运行中断，也不会无声无息地消失——而后一种正是那种让你永远不知道有三分之一的候选对象处理失败了的失效模式。 节点 1：Scanner 扫描器唯一的工作是广度。它找候选对象，并应用那些能直接判定不合格的硬过滤器。它不评估质量，因为评估质量是分析器的工作；而一个开始给东西打分的扫描器，会悄悄用没人写下来的标准去收窄漏斗。 You are an opportunity scanner. Your only job is finding candidates and applying hard filters. You do not evaluate quality or rank anything — a separate analyzer does that. DOMAIN: [what kind of opportunity you are scanning for] HARD FILTERS (a candidate failing any of these is excluded): - [non-negotiable constraint 1] - [non-negotiable constraint 2] - [legal or regulatory constraint, if any] For each candidate that passes the hard filters, return: { "name": "...", "source": "where you found it", "raw_data": { [the specific data points the analyzer will need] }, "data_gaps": ["anything the analyzer will need that you could not find"] } Rules: - Return every candidate that passes the filters, including ones that look unpromising. Ranking is not your job. - Never estimate a number you could not find. Put it in data_gaps instead. A missing number is information; an invented one is a corrupted verdict downstream. - If a filter status is unclear rather than clearly passing, include the candidate and flag the filter as UNCLEAR. Return between 10 and 30 candidates. If fewer than 10 pass, say so rather than loosening the filters. 那条"不要估算缺失的数字"的指令，是这个节点里最重要的一行。一个用看似合理的数字填补缺口的扫描器，会交给分析器一个会被套进公式、乘出结论的数字，而下游没有任何东西能发现这个结论是建立在猜测之上的。 节点 2：Analyzer 分析器对每个候选对象运行一次，并行执行。它接收原始数据，产出一个带有明确数学和陈述假设的结论。 You are an opportunity analyst. You receive one candidate and produce a scored verdict. Show all calculations. CANDIDATE: [raw_data from state] SCORING FORMULA: [your explicit formula, with the weights spelled out] THRESHOLDS: - STRONG: [specific numeric bar] - MARGINAL: [range] - SKIP: [below] Produce: 1. NUMBERS: every input you used and where it came from 2. CALCULATION: the formula applied, step by step, shown fully 3. SCORE: the resulting number 4. VERDICT: STRONG / MARGINAL / SKIP 5. ASSUMPTIONS: every assumption this verdict depends on. Be exhaustive. If you assumed a rate, a timeline, a condition holding, or a number staying stable, list it. 6. RED FLAGS: anything that would change the verdict if true Rules: - If a required input is missing from raw_data, output verdict INSUFFICIENT_DATA and name what is missing. Do not estimate it. - Show the arithmetic. A verdict without visible math cannot be verified. - Assumptions are not a formality. The verifier attacks this list. An analysis with no stated assumptions is an analysis that will be rejected. 结论阈值是数字化的，这是刻意的。STRONG、MARGINAL 和 SKIP 作为带具体数字门槛的区间，意味着后面的路由边是一次确定性检查，而不是一次模型的判断；正是这一点让系统不会因为某些仅仅"感觉有前景"的东西而唤醒你。 节点 3：Verifier 这是让整张图变得可信的那个节点，也是大多数人会跳过的那一个。 验证器是不同于分析器的另一个 agent，理想情况下运行一个不同的模型，带有一条反转其动机的指令：它的工作是杀死这笔交易，而不是确认它。一个被要求"核查这份分析"的 agent 倾向于确认它。一个被要求找出这件事为何失败的 agent 会表现得完全不同。 You are a skeptical verifier. You did not produce this analysis. Your job is to find the reason this opportunity does not work. You are not here to confirm. A verifier that approves everything provides no value. Assume something is wrong and find it. ANALYSIS TO VERIFY: [the analysis object from state] Run these checks and report each one separately: 1. ARITHMETIC: Recompute the calculation independently. Does it produce the same result? 2. INPUTS: Is each number sourced, or was any of it estimated or inferred? Flag every unsourced figure. 3. ASSUMPTIONS: Take each stated assumption and ask what happens if it is false. Which single assumption, if wrong, flips the verdict? 4. OMISSIONS: What cost, constraint, risk, or requirement is missing from this analysis entirely? 5. CONSTRAINTS: Does this actually satisfy every hard filter, or was one marked UNCLEAR and then treated as passing? Then return: { "status": "CONFIRMED | REJECTED | UNCERTAIN", "failed_checks": ["which of the five checks failed"], "reason": "the specific finding, not a general concern", "fatal_assumption": "the one assumption that would flip this" } Rules: - CONFIRMED means all five checks passed. Not "looks reasonable." - UNCERTAIN is a legitimate answer and is better than a confident wrong one. Use it when a check cannot be resolved with the information available. - A general concern is not a finding. "Market conditions could change" is noise. "Occupancy figure is a 3-month average in a market with 60% winter decline" is a finding. 最后一条规则里"顾虑"和"发现"之间的区别，正是把"增加信号的验证器"和"增加焦虑的验证器"区分开来的东西。对每个候选对象都含糊其辞地打预防针，在功能上等同于全部放行，因为它没有给你任何可行动的东西。 节点 4：Router 和 Brief 路由边是确定性代码，而不是模型决策。这很重要：一个要求模型"把好的挑出来"的 prompt，恰好重新引入了那些阈值本来设计要去除的判断。 ROUTING RULE (checked in order, first match wins): { "if": "analysis.verdict == INSUFFICIENT_DATA", "then": "archive", "tag": "data_gap" } { "if": "verification.status == REJECTED", "then": "archive", "tag": "failed_verification" } { "if": "verification.status == UNCERTAIN", "then": "brief", "section": "needs_your_judgment" } { "if": "analysis.verdict == STRONG AND verification.status == CONFIRMED", "then": "brief", "section": "act_on_these" } { "default": "archive", "tag": "below_threshold" } 注意 UNCERTAIN 路由到 brief，而不是归档。这些是系统正确地选择不做出决定的候选对象，它们往往是最有趣的那些，因为正是在这些地方，人的判断才真正增加了价值，而不是重复机器已经做过的事。 brief 本身应该短到能配着咖啡读完： Generate the morning brief from the confirmed results. ACT ON THESE: [candidates that scored STRONG and passed verification]. For each: the name, the number that makes it strong, the one assumption it depends on most, and the single next action. NEEDS YOUR JUDGMENT: [UNCERTAIN candidates]. For each: what the verifier could not resolve and what would resolve it. RUN SUMMARY: candidates scanned, analyzed, rejected and why, errors encountered. Under 400 words. If nothing scored STRONG, say that plainly in one line. Do not pad a thin run to look productive. 最后这条指令防止了任何自动化 brief 最具腐蚀性的失效模式。一个在安静的早晨编造出有趣内容的系统，会教会你不再信任它；而一份你已经学会草草略过的 brief，比没有 brief 更糟。 停止条件与成本 一张图是许多个循环，这意味着一个弱验证器或一个缺失的上界，现在会并行烧 token，而不是顺序烧。要显式地封顶，放在路由器的逻辑里，而不是放在 prompt 里。 给每次运行设置一个最大候选对象数，这样一次广扫描就不会扇出成几百个并行分析。给每个候选对象设置最大重试次数，通常是一次，超过之后该候选对象写下一个错误并退出，而不是继续循环。再设置一个每次运行的硬性成本上限，命中时就终止整个批次，无论状态如何。 然后在扩大规模之前先定范围。先拿五个候选对象跑这张图，衡量它实际花多少钱、结论有多好，然后再指向三十个。正是这一条纪律，把舒服地运行 agent 图的人，和那些在账单寄到之后才发现成本的人区分开来。 信任之前先测试 四条刻意的测试，在让它无人值守运行之前执行。 喂它一个已知的坏候选对象。拿一个你已经知道行不通的机会，确认验证器拒绝了它。如果一个刻意做坏的候选对象到达了你的晨间 brief，那验证器就是个摆设。 喂它一个缺失数据的候选对象。确认扫描器标记了缺口而不是去估算，分析器返回 INSUFFICIENT_DATA 而不是从一个编造的数字算出结论。 在运行中途弄坏一个候选对象。确认它写下一个错误、退出、并出现在运行摘要里，同时不破坏排名、不中断批次。 跑最坏情况。最大候选对象数、最大重试次数、最长的分析。算出成本。如果这个数字在一张真实的账单上会让你难受，那你的上界就太松了。 大多数在生产中失败的系统，如果当初有人跑过这些，就会立刻在其中一个上失败。 先搭循环 完整的图是四个节点、一个状态对象、一条路由规则、一组上界。别一次性全搭出来。 先从一个单一循环开始：一个 agent 接收一个候选对象，分析它，并产出一个带陈述假设的结论。手动拿一个你已经理解的候选对象跑它，把它的结论和你的判断对比。调公式和阈值，直到它们与你的判断一致。 然后把验证器加成一个真正独立的步骤，喂它一个你知道是坏的候选对象。如果它抓住了，你就拥有了那个让其余部分可以安全自动化的唯一节点。 只有到那时，再加扫描器做广度、加扇出做并行、加路由规则，加调度。 这个顺序很重要，因为它让你在把它们当成一个系统来信任之前，独立地验证每一个节点。一张一次性拼起来、从未逐个角色测试过的图，正是那种整夜漂亮运行、然后在早上递给你一份自信满满、格式工整、完全错误的清单的东西。 优势从来不是成为更好的分析师。而是过完更多的候选对象，同时不降低其中任何一个的标准。 ***这周先搭循环。下周再加验证器。 图是当这两者都跑通之后你得到的东西。*** Tags: # X # Marketing # Automation # Growth # Guide Related articles We are in the middle of the digital renaissance, please take advantage of it We're in the middle of the second renaissance where proof of work replaces the resume, an audience replaces the employer, and taste replaces credentials. AI Marketing Youtube Automation