企业官网建设流程全解析

1. 从"躺平"说起：为什么我决定把日常流程交给Agent

"躺平挖 alpha"这个说法，第一次听会觉得有点矛盾——躺平了还怎么挖？但真正做过一段时间信息处理的人会明白，这里的"躺平"不是什么都不干，而是把那些重复、机械、消耗注意力的环节交出去，让自己只保留判断和决策的部分。日常工作流优化做到第三篇，我已经不太满足于"手动整理+脚本辅助"这种半自动模式了，开始认真考虑把Agent和LLM真正嵌进流程里。

先说清楚这篇要解决什么问题。我每天要处理的信息大致分三类：一类是外部输入的原始素材，比如文章、报告、聊天记录、会议纪要；一类是中间产物，比如摘要、标签、待办、引用关系；一类是最终输出，比如周报、选题、决策备忘。过去我的做法是用一套固定的文件夹结构和命名规则来管理，配合几个Python脚本做批处理。这套东西能用，但有个致命问题：规则是死的，输入是活的。一旦素材的形态变了，脚本就得改，改完还要重新测，时间全耗在维护上。

Agent和LLM带来的变化在于，它不再要求你把规则写死。你给它一个目标，它自己决定怎么拆步骤、调什么工具、什么时候停下来问你。这听起来很美好，但实际落地时会遇到一堆问题：任务边界怎么划、失败怎么回退、上下文怎么控制、成本怎么压。这篇就把我这一轮折腾下来的完整思路和踩过的坑摊开讲，适合已经在用脚本做自动化、想再往前一步的人，也适合刚接触Agent开发、想知道真实工作流长什么样的朋友。

关键词里出现了工作流、alpha、Agent、LLM、Harness这几个词，我理解它们的关系是这样的：工作流是骨架，Agent是执行者，LLM是大脑，Harness是约束和测试框架。四者缺一不可，少了任何一个，系统都会在某个环节崩掉。下面按这个逻辑展开。

2. 把"挖alpha"翻译成可执行的工作流

2.1 先搞清楚alpha到底指什么

"alpha"这个词在不同圈子里含义差别很大。在量化里它指超额收益，在信息处理里我把它理解为"别人还没注意到、但确实有价值的信息差"。放到日常工作流里，alpha可以是一条被埋没的线索、一个跨领域的类比、一个被忽略的反常数据。挖alpha的本质，是从大量噪声里筛出少数信号，并且这个筛选过程要能持续、可复现。

我试过纯手动筛，一天下来眼睛发花，漏掉的比抓到的多。也试过纯脚本筛，关键词匹配确实快，但遇到语义相近、表述不同的内容就抓瞎。LLM的出现补上了这块短板——它能理解语义，能判断"这段话虽然没出现关键词，但意思就是这个"。但LLM也有它的问题：它会编、会跑偏、会对自己的输出过度自信。所以不能让它单独干活，得给它配一套工作流和约束。

2.2 工作流的四个阶段拆解

我把整个流程拆成四个阶段，每个阶段有明确的输入、输出和验收标准：

这个拆法的好处是，每个阶段可以独立优化，不会牵一发动全身。采集阶段出问题，不影响精筛的逻辑；精筛的prompt改了，归档格式不用动。我见过很多人一上来就想搞端到端，结果一个环节崩了整条链路都得重来，调试成本高得吓人。

2.3 为什么用Agent而不是纯脚本

纯脚本的问题是它只能执行你写死的逻辑。比如"如果标题包含A且正文包含B，就标记为候选"，这种规则写起来快，但维护起来痛苦。素材一多，规则就爆炸，最后变成一堆if-else堆在一起，谁也不敢改。

Agent的优势在于它有"判断"能力。你告诉它"帮我找出可能被忽略的有价值信息"，它会自己决定先看什么、怎么对比、什么时候觉得不确定要回来问你。这个"回来问"的机制特别重要，它把人的判断力保留在了关键节点上，而不是让人全程盯着。

但Agent不是银弹。它的判断依赖LLM，LLM有幻觉、有上下文限制、有成本。所以必须配Harness——一套约束和测试框架，确保Agent在边界内活动，出错时能回退，输出能验证。

3. Agent Harness：给自主性套上缰绳

3.1 Harness到底解决什么问题

Harness这个词直译是"马具"，引申为约束和驾驭。在Agent语境下，它指的是一套包裹在Agent外面的工程框架，负责几件事：定义Agent能做什么、不能做什么；记录Agent的每一步动作；在Agent跑偏时介入；提供测试和回退机制。

我一开始觉得Harness是多余的，Agent自己不是能判断吗？后来发现，没有Harness的Agent就像没有刹车的车，平路能跑，遇到情况就失控。具体表现有几种：一是无限循环，Agent在一个步骤上反复纠结；二是越权操作，本来只让它读文件，它去改了配置；三是幻觉累积，前一步编了个不存在的事实，后面基于这个事实继续推理，越走越偏。

Harness的核心价值是把"自主"和"可控"这对矛盾调和起来。Agent可以在Harness划定的范围内自由行动，一旦触碰边界，Harness就接管。

3.2 我实际用的Harness结构

我的Harness分三层：

第一层是权限层。明确Agent能访问哪些资源。比如采集阶段只能读指定目录，不能写；精筛阶段可以读候选池，可以写alpha清单，但不能碰原始素材。这层用配置文件定义，Agent启动时加载，运行中不可改。

第二层是动作层。记录Agent的每一步操作，包括调了什么工具、传了什么参数、返回了什么结果。这层是日志，但比普通日志更结构化，方便后面回放和调试。我用的格式是JSON Lines，每行一个动作，包含时间戳、动作类型、输入、输出、耗时。

第三层是验证层。对Agent的输出做检查。比如精筛阶段输出的每条alpha，必须包含来源引用，否则打回。验证不通过时，Harness可以选择让Agent重试、降级到人工、或者直接终止。

这三层加起来，代码量不大，但效果很明显。Agent跑偏的概率大幅下降，出问题时也能快速定位是哪一层没拦住。

3.3 一个具体的Harness配置示例

下面是我精筛阶段的Harness配置，用YAML写的，实际跑的时候加载成Python字典：

harness: name: alpha_screening permissions: read: - ./candidates/*.json write: - ./alpha_list.jsonl deny: - ./raw/* - ./config/* actions: log_format: jsonl log_path: ./logs/screening.jsonl max_steps: 50 timeout_seconds: 300 validation: required_fields: - source_url - original_text - reason min_reason_length: 20 on_failure: retry max_retries: 2

这个配置的意思是：Agent只能读candidates目录下的JSON，只能写alpha_list.jsonl，不能碰raw和config。最多跑50步，超过5分钟强制停。输出必须有来源、原文、理由三个字段，理由至少20个字。不满足就重试，最多重试2次，还不行就报错。

这套配置我调了好几轮才稳定。一开始max_steps设的100，结果Agent经常跑到80多步还在纠结，浪费时间。后来压到50，逼它早点做决定，反而效果更好。min_reason_length也是，设太短Agent就写"有价值"三个字糊弄，设太长它又凑字数，20个字是个平衡点。

4. LLM在流程里的真实角色与边界

4.1 LLM不是万能判断器

很多人对LLM的期待是"给它一段话，它告诉你有没有价值"。实际用下来，这个期待太理想化了。LLM的判断受几个因素影响：prompt怎么写、上下文给多少、模型本身的能力边界。同一个模型，prompt差一点，结果能差出天际。

我做过一个对比测试，同样的100条候选，用三种prompt让LLM判断：

最后我采用的是第三种，但做了优化：正反例不放在每次请求里，而是预先做成few-shot示例库，根据候选类型动态选最相关的2-3个塞进去。这样既保证了效果，又控制了token消耗。

4.2 上下文窗口的取舍

LLM的上下文窗口是有限资源，怎么分配很讲究。我的做法是分层：系统prompt占固定的一小块，few-shot示例占一块，当前候选占一块，历史决策摘要占一块。历史决策摘要这块特别重要，它让LLM知道前面已经筛掉了什么、留下了什么，避免重复判断和前后矛盾。

但摘要不能太长，太长会挤占当前候选的空间。我的经验是摘要控制在500字以内，只保留最近10条决策的结论和理由，不保留原文。这样既够用，又不浪费。

4.3 成本控制的几个实操手段

LLM调用是要花钱的，工作流跑起来量一大，成本很可观。我试过几个手段：

• 缓存：同样的输入不重复调用，直接返回缓存结果。这个简单但有效，尤其调试阶段反复跑同样的数据时。
• 分级：先用小模型做初筛，只把有疑问的交给大模型。小模型便宜，大模型贵，这样能省不少。
• 批处理：能合并的请求合并，减少调用次数。但要注意批处理会影响单条的上下文，得权衡。
• 早停：Agent判断明显没价值时直接跳过，不进入精筛。这个靠Harness的max_steps和Agent自己的判断结合。

实测下来，这几个手段加起来能把成本压到原来的三分之一左右，效果损失很小。

5. 踩坑实录：那些让我半夜爬起来改代码的问题

5.1 Agent陷入循环的排查过程

有天晚上跑批处理，早上起来发现Agent还在跑，日志显示它在同一个候选上反复判断了200多次。排查发现是Harness的max_steps没生效，原因是Agent调用的工具返回了一个格式不对的结果，Agent解析失败后重试，重试又失败，循环了。

修复分两步：一是Harness加了一层工具返回格式校验，格式不对直接报错终止，不让Agent自己重试；二是Agent的重试逻辑加了次数上限，超过3次就放弃并记录。这两个改动之后，再没出现过无限循环。

5.2 幻觉导致的错误归档

有一次精筛输出的alpha清单里，有一条引用的来源URL根本不存在。查下来是LLM在生成理由时，顺手编了一个看起来很像的URL。这个问题很隐蔽，因为URL格式是对的，不点开看不出来。

修复方案是在Harness的验证层加了URL可达性检查，不可达的直接打回。但这样会增加网络请求，拖慢速度。折中方案是只对最终输出的alpha做检查，中间过程不查。另外，prompt里也加了明确指令："引用来源必须来自输入文本，不得自行生成"。

5.3 上下文污染导致的判断漂移

跑了一段时间后发现，Agent的判断标准在慢慢变化。一开始它筛得比较严，后来越来越松，什么都往里放。查下来是历史决策摘要累积了太多"通过"的案例，LLM看到前面都通过了，倾向于继续通过。

解决办法是摘要里不仅保留结论，还保留当时的判断理由，并且定期重置摘要，比如每50条清空一次，重新开始。这样能防止判断标准漂移。

5.4 工具调用失败的降级策略

Agent调用的工具不一定每次都成功，网络超时、API限流、文件锁冲突都可能发生。一开始我没处理这些，工具一失败Agent就卡住。后来加了降级策略：工具失败时，Harness先重试一次，还失败就记录并跳过当前步骤，继续往下走。如果关键工具连续失败，就终止整个任务并告警。

这个策略的关键是区分"关键工具"和"非关键工具"。比如读文件是关键工具，失败必须停；写日志是非关键工具，失败可以跳过。这个区分在Harness配置里定义。

6. 从能跑到好用：工作流的持续优化

6.1 用数据驱动优化而不是拍脑袋

工作流跑起来之后，优化不能靠感觉，得看数据。我记录了几个关键指标：每个阶段的处理量、耗时、失败率、人工介入率。每周看一次趋势，哪个指标异常就查哪个环节。

比如有段时间精筛的人工介入率突然上升，查下来是LLM的prompt被我不小心改了一个词，导致判断标准变严，很多该通过的没通过。改回来就好了。如果没有数据，这种问题很难发现。

6.2 渐进式自动化而不是一步到位

我见过很多人想一步到位搞全自动，结果要么做不出来，要么做出来不敢用。我的做法是渐进式：先手动跑通流程，再半自动，最后全自动。每个阶段都跑一段时间，稳定了再往下走。

具体到我的工作流，采集阶段已经全自动了，因为逻辑简单、容错高。初筛半自动，Agent筛完我抽查。精筛还是人工为主、Agent辅助，因为准确率要求高，不敢完全放手。归档全自动，因为格式固定、可验证。

6.3 可观测性比功能更重要

工作流跑起来之后，最怕的是"黑盒"——出问题了不知道哪出的。所以可观测性比功能更重要。我的做法是每个环节都有日志，日志结构化，能按时间、按任务、按阶段查。另外加了一个简单的dashboard，实时显示各阶段的处理量和失败率，一眼能看出有没有异常。

这套东西搭起来花了两天，但后面省的时间远不止两天。没有可观测性，调试就是盲人摸象。

7. 一些零散但重要的经验

关于Agent的自主性，我的体会是：自主性不是越高越好，而是要和任务的风险匹配。低风险任务可以给高自主，高风险任务必须给低自主。判断风险的标准是：出错了能不能发现、发现了能不能回退、回退的成本高不高。

关于LLM的选型，不要迷信大模型。很多任务小模型够用，而且快、便宜。我的做法是先用小模型跑，效果不够再换大的。换的时候注意prompt可能要调整，不能直接套。

关于Harness的维护，它本身也是代码，也会过时。我每个月review一次Harness配置，看看权限有没有多余、验证规则有没有失效、日志有没有膨胀。这个习惯帮我避免了好几次潜在的事故。

关于工作流的扩展，不要一开始就设计得太复杂。先跑通最小闭环，再逐步加功能。我第一版工作流只有采集和归档两个阶段，中间全靠手动。后来才慢慢加上初筛、精筛、Harness。如果一开始就设计五个阶段，可能到现在还没跑起来。

最后说一个具体的技巧：Agent的prompt里加一句"如果不确定，标记为待人工复核，不要强行判断"。这句话能大幅降低误判率。LLM有时候会为了"完成任务"而强行给结论，加了这句话之后，它会老实说"我不确定"。待人工复核的条目虽然要人看，但比错误结论造成的损失小得多。

这套工作流我跑了三个月，中间大改过两次，小调过无数次。现在它每天帮我处理几百条素材，筛出十几条候选，我只需要花半小时复核和归档。省下来的时间，才是真正用来"挖alpha"的时间。工具的意义不是替代人，而是把人从机械劳动里解放出来，去做只有人才能做的事。