中文精读
Sheet0谈Agent：先定义交付结果，再构建环境反馈
42章经单期精读 · Agent实践
嘉宾：王文锋，节目当期介绍为Sheet0创始人兼CEO、连续创业者，拥有近十年AI与数据基础设施产品及编程经验｜主持：曲凯
节目发布：2025年4月19日｜时长：52分38秒｜整理：2026年10月18日
收听原节目与查看官方介绍
这期的主线：结果决定反馈，反馈决定下一步
王文锋用模型、环境反馈和工具行动解释Agent。放到产品里，这意味着一个连续过程：系统观察当前情况，调用工具，得到结果，再用新信息决定下一步。
这期最有用的地方，是把几个常被分开讨论的问题接起来：Context（当前任务可用的信息）从哪里来，工具怎样复用，用户怎样参与，以及最终交付物怎样被检查。
本文依据完整提供的文字稿及官方介绍整理。Sheet0当时刚开放候补申请，节目中的成功率、竞品比较和未来时间表均为当期陈述。文末另标出2026年回访，帮助读者区分早期承诺与后续认识。
1. Context包括执行过程新产生的信息
节目线索：02:32–04:07、27:14–31:28。 在代码任务里，上下文可以是代码库结构、源文件、API和用户需求；在Sheet0的数据任务里，还包括网页、已收集的表格、生成的SQL及执行结果。
重要的一步是让行动结果进入下一轮判断。例如，网页里混有无关内容，需要提取；生成SQL后，需要在环境中执行并检查反馈。仅保留最初需求和最后答案，会丢失中间为何改路、哪里报错的信息。
王文锋也强调产品场景本身提供意图线索。用户进入一个数据工具，已经收窄了可能要做的事情；再通过历史任务、工具结果和必要澄清逐步明确目标。
编辑判断：上下文应覆盖任务需要的来源、过程和状态。保留这些信息有助复盘，但不意味着应无边界收集所有用户行为。尤其要区分：当前知道什么，哪些仍未知，以及哪些信息需要用户授权才能取得。
2. 现成工具先复用，缺少能力时再生成代码
节目线索：04:41–10:27、15:04–16:12、34:18–35:19。 访谈中，MCP、API调用和浏览器操作被放到同一个问题下：系统如何采取行动。浏览器也可以封装成工具，代码和视觉操作可以组合使用。
王文锋反复强调复用。每次任务从头生成所有步骤，会消耗时间并带来重复调试；已有经过测试的执行部件，就先调用，缺能力时再让AI编程补充。
这给出了一个可辨认的工程分工：模型处理任务理解和开放判断，执行部件承接成熟动作，代码生成补足尚未覆盖的步骤。具体怎样组合，需要看任务、工具可用性和失败代价。
编辑判断：协议名称不构成可靠性证明。节目将不同工具协议类比为版本演进，只是帮助理解的说法，不能当正式标准关系。视觉操作的成本优势也是嘉宾在特定条件下的观察；具体场景仍应比较正确率、成本和恢复能力。
3. 把“需要反馈”落实为产品能观察的状态
节目线索：17:37–22:43、47:56–51:14。 王文锋借强化学习的状态、行动和激励信号，提出一个产品设计问题：做完这一步后，系统怎样知道自己更接近目标？
IDE能运行代码、返回错误，是他举的具体例子。一个单纯的运行容器还需要工具和检查机制，才能提供有用反馈。对数据任务，脚本执行结果和结构化字段也可以成为检查入口。
他对“只让模型判断自己好不好”的担忧很实际：如果反馈只有“不满意，再改”，系统可能反复改写，却始终不知道哪个要求没满足。
编辑判断：可以借用这套问题设计任务，不必由此推导出所有Agent团队都要训练强化学习模型。运行时根据结果修改下一步，与用奖励更新模型参数，是不同层面的工作。
4. 一张表格怎样成为可交付的数据结果
节目线索：31:54–41:22。 Sheet0当时定位为数据收集、处理、进一步行动的链路。节目举了两个场景：从开源用户的公开线索识别公司；收集某些YC批次的公司，再补创始人及相关信息。
王文锋强调先形成完整、干净的结构化表格，再做定量分析。与直接给出一篇研究报告相比，表格更容易逐行、逐字段检查。但他声称能保证全部抓取、完全准确，访谈没有提供独立任务集和验证记录支撑这一保证。
编辑应用示例：如果任务是收集指定批次的公司，至少需要这些检查，才能解释表格完成了多少：
| 要检查什么 | 应保留的证据 | 仍然不能推出什么 |
|---|---|---|
| 范围与总量 | 指定批次、来源目录、页数和起止边界 | 搜索到若干条就是全量 |
| 唯一性 | 公司ID或规范地址、去重规则 | 行数相同就没有重复或遗漏 |
| 字段来源 | 每个关键字段的来源和采集时点 | 单元格非空就内容正确 |
| 未完成项 | 缺失、受限、冲突与待确认原因 | 无法访问等于不存在 |
| 后续动作 | 联系建议与实际发送分开记录 | 完成资料收集就获准发信 |
这些是从访谈问题延伸的验收建议，不是已验证的Sheet0内部实现。表格使错误更容易定位，完整性和语义仍要靠具体证据判断。
5. 过程可见与结果可信，需要分别做好
节目线索：10:49–14:02、40:28–44:21。 王文锋重视让用户看到浏览器怎样操作，以建立掌控感。主持人也指出一个反例：用户等了很久，回来发现系统早已停在一个没被注意到的澄清问题上。
因此，过程展示还需要告知下一步需要谁处理。等待用户的任务应有清楚状态，用户回来后能接续；结果页也应说明完成范围与异常。
王文锋同时提醒开发者了解模型能力，避免无谓规则限制泛化。可从中提炼出两种责任：让模型有空间寻找解决路径，同时在权限、外部动作和结果验收上保留明确约束。
编辑判断：动画、浏览器轨迹或可读推理能帮助理解过程，却不能单独证明采集完整或结果正确。选产品时，需要分别看用户是否理解当前状态，以及最后交付物是否经过检查。
后续补充：2026年，他怎样重看“百分百准确”
在2026年3月14日的回访中，51:51–53:20，王文锋重新谈到上一阶段追求百分百可信、可解释和准确的目标。他承认当时模型做不到，并认为用户在那个阶段最迫切的阻塞点未必是绝对准确；回访当时，他更关注工程师同时管理多个终端的注意力问题。
这是后一个时点的自我复盘，不能倒填成2025年已经承认的限制。把两期并置，可以同时保留工具复用与外部反馈的工程价值，并看到目标、模型能力和用户实际瓶颈之间的变化。准确性仍需验收，早期营销承诺则需要明确限定。
用这期检查一项Agent任务
编辑建议从一个具体交付物开始，写清输入范围、可用动作、完成条件和需要人工确认的例外。再逐步回答：
- 哪些上下文可以自行取得，哪些必须问用户？
- 每次行动后有哪些可观察的新结果？
- 哪些执行部件已经测试，可以直接复用？
- 遇到缺失、权限问题或结果不明时，停在哪里？
- 用户最终收到什么，凭什么确认它完成了？
这个顺序适合数据整理、研究与工具执行类任务。创作和开放探索可以使用不同的验收方式；不必将所有结果强行压成表格，也不能因为任务范围较窄就承诺绝对可靠。
回听导航与关联阅读
- 02:32：上下文的范围与来源。
- 15:04：工具复用和AI编程的分工。
- 18:09：状态、行动与反馈信号。
- 26:03：聊天入口与适时出现的界面组件。
- 32:13：Sheet0的数据任务案例。
- 48:20：怎样判断一步行动做得好不好。
Agent架构与多Agent编排 · 同系列：Dify单期精读
资料边界：这篇是单期机制分析，非产品横向实测或完整逐字稿转载。姓名、SQL等术语按官方介绍和上下文校正；未逐句复听音频。2026年回访仅用于明确标记的跨期补充，没有据此认定当前产品效果。
English edition
Sheet0 on Agents: Define the Deliverable, Then Build Environmental Feedback
42 Zhangjing episode analysis · Agent practice
Guest: Wang Wenfeng, introduced as Sheet0 founder and CEO, a repeat entrepreneur with nearly ten years of AI, data-infrastructure product and programming experience | Host: Qu Kai
Published: April 19, 2025 | Duration: 52 minutes 38 seconds | Prepared: October 18, 2026
Listen to the episode and read its official introduction
The central connection: Results define feedback, and feedback informs the next action
Wang explains agents through models, environmental feedback and tool-based action. In a product, these form a continuing process: observe the current situation, invoke a tool, obtain a result and use the new information to decide what to do next.
The episode connects questions often discussed separately: where context—the information available to the current task—comes from, how tools are reused, how users participate and how the final deliverable can be checked.
This article draws on the complete supplied transcript and official introduction. Sheet0 was opening its waiting list at the time. Success rates, comparisons and forecasts are statements from that period. A separately labeled section adds the guest’s 2026 return interview to distinguish early promises from later reflection.
1. Context includes information generated during execution
Episode reference: 02:32–04:07 and 27:14–31:28. In a coding task, context can include repository structure, source files, APIs and user requirements. For Sheet0’s data tasks, it also includes web pages, collected tables, generated SQL and execution results.
The important step is bringing action results into the next decision. Irrelevant web content needs filtering; generated SQL needs execution and feedback. Retaining only the initial request and final answer loses information about why the system changed course or where an error occurred.
Wang also argues that the product’s setting supplies clues about intent. Entering a data tool already narrows the likely task. Prior work, tool results and necessary clarification further specify the goal.
Editorial interpretation: Context should cover the sources, process and state required by the task. Keeping that information helps review, but does not justify collecting every user action without limits. Distinguish what is known, what remains unknown and what requires user authorization to obtain.
2. Reuse existing tools before generating missing capabilities
Episode reference: 04:41–10:27, 15:04–16:12 and 34:18–35:19. MCP, API calls and browser interaction are considered under one question: how does the system act? Browsers can be wrapped as tools, and code and visual interaction can be combined.
Wang repeatedly emphasizes reuse. Generating every step from scratch consumes time and introduces repeated debugging. Use tested execution components where they exist; generate code to fill missing capabilities.
This suggests a recognizable division of work: models interpret tasks and handle open-ended judgment, execution components perform established actions and code generation fills uncovered steps. The combination depends on the task, available tools and consequences of failure.
Editorial interpretation: Protocol names do not prove reliability. The interview’s comparison of tool protocols to successive versions is an explanatory analogy, not their formal standards relationship. The proposed cost advantage of visual interaction is also an observation under particular conditions. Actual tasks still require comparisons of accuracy, cost and recovery.
3. Turn “we need feedback” into observable product state
Episode reference: 17:37–22:43 and 47:56–51:14. Drawing on reinforcement learning’s state, action and reward concepts, Wang asks a practical design question: after a step, how does the system know whether it is closer to its goal?
An IDE that runs code and returns errors is his concrete example. A runtime container needs tools and checks around it to supply useful feedback. Script results and structured fields can provide inspection points for data tasks.
His concern about asking a model alone to judge its quality is practical. If the feedback is only “unsatisfactory, revise it,” the system may repeatedly rewrite without knowing which requirement it missed.
Editorial interpretation: Teams can use these questions to design tasks without concluding that every agent company must train reinforcement-learning models. Changing the next action in response to a runtime result and using rewards to update model parameters are different activities.
4. How does a table become a deliverable data result?
Episode reference: 31:54–41:22. Sheet0 was positioned around collecting data, processing it and taking subsequent action. The episode gives two examples: identifying companies from public clues associated with open-source users, and collecting companies from selected YC batches before adding founder information and related details.
Wang emphasizes building a complete, clean structured table before quantitative analysis. Compared with delivering a research narrative directly, tables make row-level and field-level inspection easier. However, his guarantee of complete collection and absolute accuracy was not supported by an independent task set or validation record in the interview.
Editorial application example: For a task collecting companies from specified batches, at least the following checks help explain how much of the table is complete:
| Check | Evidence to retain | What it still does not establish |
|---|---|---|
| Scope and totals | Specified batches, source directory, page counts and start/end boundaries | A few search results represent the full set |
| Uniqueness | Company IDs or canonical addresses and deduplication rules | Matching row counts mean there are no duplicates or omissions |
| Field provenance | Sources and collection times for important fields | A populated cell contains correct information |
| Unfinished items | Reasons for missing, restricted, conflicting or uncertain data | Inaccessible information does not exist |
| Subsequent actions | Separate contact recommendations from actual messages sent | Collecting information authorizes sending messages |
These are acceptance suggestions developed from the interview’s questions, not verified descriptions of Sheet0’s internal implementation. Tables help locate errors; completeness and meaning still require specific evidence.
5. Make both the process understandable and the result trustworthy
Episode reference: 10:49–14:02 and 40:28–44:21. Wang values showing browser actions to give users a sense of control. The host supplies a counterexample: after waiting a long time, a user discovers that execution stopped earlier at an unnoticed clarification question.
Process visibility therefore also needs to communicate who must act next. Tasks waiting for a user should have clear state and support resumption. Results should explain completion scope and exceptions.
Wang also asks developers to understand model capabilities and avoid unnecessary rules that constrain generalization. Two responsibilities can be drawn from this: allow room to explore a solution while retaining explicit constraints around permissions, external actions and acceptance of results.
Editorial interpretation: Animations, browser traces and readable reasoning can aid understanding, but cannot independently establish complete collection or correct results. Evaluate whether users understand the current state and whether the final artifact was checked as separate questions.
Later reflection: Revisiting “100% accuracy” in 2026
In the March 14, 2026 return interview, at 51:51–53:20, Wang revisits the earlier objective of complete trustworthiness, explainability and accuracy. He acknowledges that models could not achieve it at that stage, and argues that absolute accuracy was not necessarily users’ most pressing bottleneck. At the later interview, his attention had shifted toward engineers managing many terminal windows.
This is a later retrospective and must not be presented as an acknowledgment already made in April 2025. Reading the two interviews together preserves the engineering value of tool reuse and external feedback while revealing changes in objectives, model capabilities and user bottlenecks. Accuracy still requires acceptance testing; early promotional promises need explicit qualification.
Use the episode to examine one agent task
An editorial exercise is to begin with a specific deliverable and define input scope, available actions, completion conditions and exceptions requiring a person. Then ask:
- Which context can be obtained independently, and which questions require the user?
- What new results are observable after each action?
- Which tested execution components can be reused?
- Where should execution stop when information is missing, permission is absent or a result is unclear?
- What does the user receive, and what evidence establishes completion?
This sequence suits data organization, research and tool-execution tasks. Creative work and open exploration can use different acceptance methods. Every result need not be forced into a table, and a narrower task does not justify a promise of absolute reliability.
Listening guide and related reading
- 02:32: The scope and sources of context.
- 15:04: Tool reuse and the role of AI coding.
- 18:09: State, action and feedback signals.
- 26:03: A chat entry point with interface components appearing when needed.
- 32:13: Sheet0’s data-task examples.
- 48:20: Determining whether an action was good or bad.
Agent architecture and multi-agent orchestration · From this series: Dify episode analysis
Source boundary: Mechanism analysis of one episode, not comparative product testing or full transcript republication. Names and terms such as SQL were corrected against the official introduction and context. Audio was not replayed sentence by sentence. The 2026 return interview is used only in its labeled later-reflection section and does not establish present product performance.